| Summary: | very slow when delete photos and albums | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Kirill <kirill_v_b> |
| Component: | Database-Mysql | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin, riverheart201 |
| Priority: | NOR | ||
| Version: | 5.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | 7.9.0 | |
| Sentry Crash Report: | |||
|
Description
Kirill
2016-10-09 17:08:26 UTC
Additional info.
1. Photos collection located at mounted network disk.
2. 2-5 minutes for deleting photos and folder only in case if collection located in root of Albums. Like this :
Albums
|
-->My Collection
|
-->Photo1
|
-->Photo2
|
-->etc...
But, if we place all folders 1 level deep (see schema bellow) from root - everything will start working very fast as expected:
Albums
|
--> My Collection
|
-->All photos
|
-->Photo1
|
-->Photo2
|
-->etc...
A new fresh 5.8.0 pre-release PKG installer for MacOS was just rebuild for testing and is available here : https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Please confirm if the problem remains with this version. Thanks in advance Gilles Caulier On Reddit we are discussing the possibility that slow delete performance may be related to the size limit option. Performance seems to be greatly increased. Is it possible that every delete operation iterates the entire contents of the recycling bin to determine the size, or there's some other slow code path that happens through that option? I also noticed that file move operations are similarly much faster with the option unchecked, so this issue could be bigger than it seems. This may be related to #402704 402704 is about dolphin and Plasma trash. digiKam do not use desktop trash which is relevant of KIO and is not portable under MAcOS and Windows. Each collection has a hidden trash folder which is located on top of collection directory. DK trash is has the same place than collection so deleting collection files is just a move on same file system. This is perfect for remote or removable collections. Gillees Caulier As Gilles writes, it is a quick file move because the digiKam trash is on the same partition as the collection. However, we have to do something in the database after each move, the file must be marked as deleted (trashed), etc. Depending on the database, this takes a little time. I no longer find the deletion process slow. MySQL is quite a bit faster here. Maik digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best Regards Gilles Caulier https://bugs.kde.org/show_bug.cgi?id=426938 --- Comment #4 from caulier.gilles@gmail.com --- Hi, digiKam 7.2.0-beta2 pre-release PKG installer now support BigSur and is compiled with last stable Qt 5.15.2. https://files.kde.org/digikam/ Problem still reproducible with this version. Thanks and happy Christmas in advance Best Regards Gilles Caulier |