SUMMARY Startup to GUI factor 4 slower than with previous versions. 15 minutes for al collection with 400 k images More than 1h for a collection with 1,5 M images STEPS TO REPRODUCE Initial startup to the GUI (the time during which the splash screen is showing)has become agonizing slow when using large image collections. As soon as the "scanning for new items" begins, the program works as expected. This behaviou has been observed on two different machines (both Windows 11 with the most recend MariaDB and all files (both images and database on fast SSDs, 32 GB RAM on the smaller machine, 128 GB on the larger machine). Since Startup is a factor 4 faster when I revert to one of the oder versions (e.g. 8.5), I conclude that it is not due to the external database. SOFTWARE/OS VERSIONS Windows: Version 11 MariaDB: 11.6.2
Hi Problem already reported. Please double check the 4 first options on the Behaviors page from Setup/Miscs settings: https://docs.digikam.org/en/setup_application/miscs_settings.html#behavior-settings Also we make few optimization in current 8.7.0: https://files.kde.org/digikam/ Best regards
Git commit 30af905afd029b0aa9a8632c39694e4f74ac9be7 by Gilles Caulier. Committed on 12/05/2025 at 07:01. Pushed by cgilles into branch 'master'. Add red annotation about startup Behaviors options which can makes application initialiation slower M +54 -46 core/utilities/setup/misc/setupmisc.cpp https://invent.kde.org/graphics/digikam/-/commit/30af905afd029b0aa9a8632c39694e4f74ac9be7
Hello, I am facing the same problem. Comparing versions 8.6.0 and 8.5.0, both built from sources, version 8.6.0 starts significantly slower than version 8.5.0, all the above options disabled OS: openSUSE Tumbleweed Qt version: 6.8.2
Created attachment 181248 [details] Test database with 11K Tags Here is a dummy SQLite database with 11K tags&images on which this problem occurs. Startup time: v8.6.0: 1m20s v8.5.0: 12s
Git commit f0e366bd5b3e1f9c8eeed3c8402f5515c7cc45c2 by Maik Qualmann. Committed on 13/05/2025 at 20:15. Pushed by mqualmann into branch 'master'. revert a fix for the album counter update This leads to a massive slowdown when loading album/tag items into the model. Related: bug 389046 FIXED-IN: 8.7.0 M +1 -1 NEWS M +0 -25 core/libs/album/treeview/abstractcountingalbumtreeview.cpp M +0 -4 core/libs/models/abstractalbummodel.h M +9 -2 core/libs/models/abstractalbummodel_counting.cpp M +15 -1 core/libs/models/albummodel_tag.cpp https://invent.kde.org/graphics/digikam/-/commit/f0e366bd5b3e1f9c8eeed3c8402f5515c7cc45c2
The changes by Maik Qualmann 2025-05-13 20:24:28 UTC / incororated in version 8.7 definitely helped so speed up things. Thanks! With the unfixed version 8.6 startup was more than 1h for a collection with 1,5 M images. It is now down to 10 minutes for the same collection. Cool! However, in my notes I find that startup was only 3 minutes earlier this year (using digiKam-8.3.0-Qt5-Win64). Meaning, that startup for version 8.7 is still a factor 3 slower than it was before :-(
The reason may well be Qt6 compared to digiKam-8.3.0, which still used Qt5. QDateTime operations have become slower, as calendar/time zone calculations are now more accurate. This is why we switched to UTC internally, as otherwise, many date calculations would have been significantly slowed down. It's important to remove digiKam from your antivirus program. Disable internal debug logging; the Windows kernel is very slow when it comes to debug output. Otherwise, please create a DebugView log from startup, as described here: https://www.digikam.org/contribute/#windows-host Maik
Maik, thanks for the suggestions. - I added an exclusion for digikam.exe in the Windows Defender. No change in startup time at all. - Internal debug logging was off at the time. - As suggested, I generated a DebugView log which I'm going to attach in a minute. On a side notice: When I started digiKam to generate the log trace, it ended up in a totally unusable state (menus were accessible, thumbs showed up only as outlines, full screen viewing of the images did not work at all). This might or might not be a completely different issue. I reported it some time ago as https://bugs.kde.org/show_bug.cgi?id=504250 which has been marked as as duplicate of https://bugs.kde.org/show_bug.cgi?id=502858. This behavior showed up on two independed machines, most prominently for the machine on which I host a really huge collection (nearly 2 M image, 20 k tags). Both run on Windows 11, MariaDB 11.6.2. Thanks for your good work and write a note if you need more information to track this problem. Andreas
Created attachment 184758 [details] DebugView trace
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
Forgot to set the flag to "reported" after providing the debug trace on September 5. Sorry. I hope the provided information helps.