SUMMARY Selecting items from Icon or Table view becomes slower when more items are in the view. This appears to be caused by the loop in DigikamApp::slotImageSelected that totals the item sizes. STEPS TO REPRODUCE 1. Open an Icon view with 10000 images 2. Add some images to the selection 3. OBSERVED RESULT Each time the selection changes, the GUI lags or locks up EXPECTED RESULT No lag please SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.17 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.12.16-gentoo (64-bit) Graphics Platform: X11 Processors: 8 × AMD FX(tm)-8320 Eight-Core Processor Memory: 18.6 GiB of RAM Graphics Processor: OLAND ADDITIONAL INFORMATION Seems like this loop should be tied to refresh of the view instead of the selection. Also, if the status bar or properties pane aren't displayed then there isn't a reason to do the calculation.
It's reproducible with last 8.6.0 ?
The cause is more likely which right sidebar you have open. Calculating the file size of the selection isn't really a problem. The Captions sidebar causes a slowdown because it has to query the metadata status in the selection to determine whether different titles, captions, tags, color labels, etc. are present. This takes time, depending on when the search can be canceled based on the assigned metadata. However, we can't change this if we want to maintain functionality. Maik
The problem is calculating the total size of all DISPLAYED items every time the selection is changed. Removing this loop eliminates most of the lag for me: for (const ItemInfo& info : std::as_const(listAll)) { // cppcheck-suppress useStlAlgorithm listAllFileSize += info.fileSize(); } As currently seen at https://invent.kde.org/graphics/digikam/-/blob/master/core/app/main/digikamapp.cpp#L693-697 This loop might have less observable impact if using the baloo code path (I don't have baloo).
The solution to this problem will be to compute the properties of the selection, in a separated thread, and to update the GUI when all is done.
Something similar done with histogram computation from the Color tab.
Calculating the file size doesn't need to be done in a separate thread. The ItemInfo value info.fileSize() is a cached value. I tested it with 50,000 items on my old computer, and there was no delay in selecting. The problem only occurs if the Captions sidebar is currently enabled; in that case, reading the metadata status would have to be done in a separate thread. Maik
Revisiting this again. This has absolutely nothing to do with the right sidebar. According to perf, most time is spent in Digikam::ItemInfoCache::getImageGroupedCount
How do you know that ItemInfoCache::getImageGroupedCount is a problem? Yes, this function is called very frequently, which is why it's needed when drawing/redrawing items. But the database access only occurs once, when the view is loaded; after that, the result is read from a memory cache. This has absolutely no impact on execution speed. Maik
I'm not experiencing any latency when selecting multiples of 10,000 items. Are you using Wayland? Maik
I use X11. I ungrouped all images (about 120,000 raw+jpgs) and there is no lag anymore. There is clearly a performance problem that worsens at the rate of number of items in the view multiplied by number of rows in imagerelations table. 1. There seems to be a signal/slot that is causing info cache to be invalidated on selection (not sure which) 2. ItemInfo::hasGroupedImages() is not optimized for its task (it runs getImageGroupedCount(), which ultimately has to iterate over the entire imagerelations table. Even if cache hasn't been invalidated, this is silly. https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/item/containers/iteminfo_groups.cpp#L23-26 https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/item/containers/iteminfocache.cpp#L71
I debugged it again; while selecting items, there is no database query of the relation table; everything comes from the cache. The cache is only rebuilt when the album is loaded or items are grouped. If there is an invalidate signal, you have some other database problem. Please create a debug log of the process, as described here for Linux: https://www.digikam.org/contribute/#linux-host Maik
Ken, Do you seen the last Maik comment ? Gilles Caulier