I have measured the startup time of digikam, and it stays 2 minutes and 10 seconds in the splash screen before showing the main interface. I am using digikam 5.8.0 in Windows 10 (64 bit), the photos are in a network share (although it doesn't seem to use network traffic during startup), initial scan and database cleanup are disabled. I have a normal hard disk drive (not SSD), in a i5-3570 machine with 16gb or ram, and the database is stored locally, which contains ~100000 photos. Just for a quick comparison, another digital picture manager manager I use, picasa, takes 4 seconds to launch the main interface, with exactly the same pictures on it. That means it is 32 times faster.
Go to digiKam Setup dialog, into Misc/Behavior section and to disable the "scan for new item at startup" option. Gilles Caulier
Yes, that's after disabling the "scan for new items at startup" option. If you include the initial scan, it is much much slower (I'll measure it later).
Well, the long initialization is not due to scan stage, but to load database contents, certainly the previous searches albums created. Did you perform a similarity search before ? A debug trace capture of start up with debugview program from Microsoft can help to investigate. Gilles Caulier
Sorry, I am not sure I understand. I have 6 or 7 saved searches, if that's what you mean. At this point, there are no new items, all albums have been scanned previously. I used debugview while starting digikam. This is the result: (name of the sources have been changed for privacy reasons) https://pastebin.com/SzJSTGxW The big delay appears between line 132 and 133.
Between lines 132 and 133 there is nothing to see... Which kind of search albums did you have exactly ? Gilles Caulier
I had 7 saved searches. Most of them just searching for a word (e.g. the name of a trip I made) and two of them was a search showing two people tags. I deleted all of them and tried again. It now took 111 seconds from the splash screen to the main interface. (the log file looked similar, nothing between those timepoints)
Created attachment 110376 [details] blockSignals.patch This patch prevents time-consuming searches from being started when loading the GUI. The patch has to be tested even longer, if side effects occur. Maik
Note: This patch only helps if the left sidebar with the search is not open at startup. So if at startup the album tab is active. Maik
Git commit 276627e6d8e3b3060ef268ea538081506fc63e56 by Maik Qualmann. Committed on 07/02/2018 at 18:58. Pushed by mqualmann into branch 'master'. block signals when the current index is restored in the tree views M +6 -0 libs/album/albumtreeview.cpp https://commits.kde.org/digikam/276627e6d8e3b3060ef268ea538081506fc63e56
Git commit e6e76cf0cf8b34f028511958070f98f457eef81a by Maik Qualmann. Committed on 15/09/2019 at 06:47. Pushed by mqualmann into branch 'master'. less locked database during the initial scan Related: bug 389652, bug 411927 FIXED-IN: 6.4.0 M +3 -1 NEWS M +8 -4 core/libs/database/collection/collectionscanner_scan.cpp https://invent.kde.org/kde/digikam/commit/e6e76cf0cf8b34f028511958070f98f457eef81a