| Summary: | Very slow startup [patch] | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
| Component: | Database-Scan | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, iwannaberich, metzpinguin |
| Priority: | NOR | Keywords: | usability |
| Version: | 5.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/kde/digikam/commit/e6e76cf0cf8b34f028511958070f98f457eef81a | Version Fixed In: | 6.4.0 |
| Sentry Crash Report: | |||
| Attachments: | blockSignals.patch | ||
|
Description
MarcP
2018-02-06 13:03:06 UTC
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 |