Created attachment 172834 [details] Debug log Renaming a batch of images based on their metadata is extremely slow. It's as though it's rewriting the whole file with a new name instead of just moving it. Very noticeable on a network share (2 seconds per files in my case). STEPS TO REPRODUCE 1. Select multiple files from the Album view 2. Press F2 to rename 3. Apply a new naming format and press Ok to begin renaming OBSERVED RESULT Each rename takes much longer than expected compared to a file move operation in the same location. EXPECTED RESULT Fast rename by just using a move operation with a new name. SOFTWARE/OS VERSIONS Windows: 10 Logs attached Rename starts at line 3376
This is how Exiv2 patch files with metadata. A copy of original is done in temporary very, changes are applied, and at end temporary file is renamed. For few type of file as JPEG or TIFF, the file is not reencoded, for other the operation is more complex. This is how Exiv2 works in background. The only solution to prevent time latency in GUI is to fork all metadat operations in a separated thread. About metadata and database cache, not all information are store in database. This depend of options passed in the advanced rename settings. Gilles Caulier
Unfortunately, the renaming function has to do a little more, e.g. search for sidecar files and rename them if they exist. This obviously leads to a significant slowdown on a network drive. The file also has to be renamed in the database and thumbnail database. Maik
Thanks for the information on how this works - useful to know. Based on this, is it most likely the sidecar file search that is taking the most time? I can't see why Exiv2 would have to get involved for the actual rename operation - would it not only be the generation of the new name that requires Exiv2. After the name is generated, couldn't it just use standard OS move calls?
You should activate the WAL mode for the SQLite database, in the digiKam settings under database. This increases the performance of the SQLite database. No Exiv2 is used when it comes to the execution of the renaming, only when preparing. Maik
Git commit 57fc5bd6244991e0df7bcc4e27b488d109d10644 by Maik Qualmann. Committed on 22/08/2024 at 19:52. Pushed by mqualmann into branch 'master'. do not read the entire directory to see if the file already exists M +1 -7 core/libs/iojobs/iojob.cpp https://invent.kde.org/graphics/digikam/-/commit/57fc5bd6244991e0df7bcc4e27b488d109d10644
Maik, I identified also this code which take age with large items list to rename : https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/advancedrename/advancedrenamedialog.cpp?ref_type=heads#L91 Gilles
The item setImageUrl() is called in constructor for each item on the list in this loop : https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/advancedrename/advancedrenamedialog.cpp?ref_type=heads#L317 Gilles
Really, for is faster than Q_FOREACH? That's interesting. Maik
Not faster but better. Q_FOREACH is also deprecated to use since we uses C++17. There is a switch not yet enabled to break the compilation when using Q_FOREACH. Gilles
Maik, look the details at end of this page : https://doc.qt.io/qt-6/foreach-keyword.html Q_FOREACH copy the data, for C+11 use a detached one. So typically, it must be a little bit faster i think. Gilles
Maik, KDAB has a good blog entry about the Q_FOREACH to for C++11 migration : https://www.kdab.com/goodbye-q_foreach/ Gilles
Gilles, have you noticed this? https://www.kdab.com/blog-qasconst-and-stdas_const/ Maik
yes, i seen. Clazy static analyzer will report this kind of change to do in the code where it's can do it. So i will fix the code in a second pass. Gilles
Do we want to use qAsConst()? It's shorter and we already use it. ((:-)) Maik
yes, done... Gilles
Maik, Note that it still more than 1000 occurrences of Q_FOREACH in whole digiKam to patch... Gilles
Maik, With Qt 6.7.2 and clang : warning: 'qAsConst<...>' is deprecated: Use std::as_const() instead. [-Wdeprecated-declarations] Gilles
Ok, then we can't use qAsConst()... Maik