[Digikam-devel] performance problems with recursive view and filtering
caulier.gilles at gmail.com
Fri Jan 4 16:23:22 GMT 2008
2008/1/4, Arnd Baecker <arnd.baecker at web.de>:
> with the new recursive view of albums and the quick filters in the
> status bar some performance problems become visible
> when the number of involved images becomes large.
> Let me describe a couple of cases for an album with 16289 images
> (let's call that "2007" in the following);
> for the tests below "Include Album Sub-Tree" is activated.
> (of course, the slower your computer, the more clearly the effects
> will be visible...).
> 1.) - Start from an album with a small number of images (e.g 24).
> The status line says "img_xx.jpg (1 of 24)"
> - Switch to "2007".
> The status line does not change for quite some time
> (approx 5s on a reasonably fast machine).
> There is no visual indication, that something is happening.
> Question: Can the whole process be made faster?
> Possible solution: a progress bar should be added (see also below)
There is already a progress bar in status bar used when you assign a tag to
a large collection of image, or to prepare a slideshow.
Attempt at an analysis:
> After the selection of "2007" dozens of calls to
> void AlbumIconView::slotImageListerNewItems
> followed by
> take place.
> Only at the very end
> gets called.
> Is there anything in these steps which could be optimized?
> 2.) Start from "2007" and activate the rating filter (e.g. >= 5stars).
> Here a visual indication in terms of an hour glass as mouse cursor
> is given (however that does not appear immediately).
> In my case I get 52 pictures, but it takes about 14 seconds!
> (Sometimes the status line is not updated properly at the end?)
> Attempt at an analysis:
> Most of the time is spent in AlbumLister::slotFilterItems()
> While the first loop in that routine is not extremely fast,
> it is the second part after the comment
> // This takes linear time - and deleting seems to take longer.
> // Set wait cursor for large numbers.
> If I understand things correctly, this means that in the example
> 16289 - 52 images get deleted.
> This looks like the place to be optimized
> (by a better strategy, I would guess ...).
> This also explains, why changing between 4 and 5 star filtering
> (593 vs. 52 results) is faster.
> In this case, the bottle-neck is the first loop in
> which calls
> for each item.
> ((Note: We might have to be careful with adding too much complexity
> in the matchesFilter, or use more clever strategies))
> Speed improvements to the first loop would be therefore be
> very helful, also in view of the next point.
> 3.) Start from "2007" (with all images) and type some text in
> the text filter.
> - if you don't type very fast (I did not manage),
> one will not see the 2nd letter of a word for a while.
> The reason is that for a new text
> void AlbumLister::setTextFilter
> is called, which sets the filterTimer.
> void AlbumLister::slotFilterItems()
> is called, before the next call to
> void AlbumLister::setTextFilter
> becomes active.
> - Then the main bottle-necks are as in 1.) and 2.).
> As a short term solution I would suggest to
> put the waitCursor at the beginning of
> void AlbumLister::slotFilterItems(),
> if d->itemList.count() > 500 (etc.)
> This should give some visual feedback.
Should I open a new bug report with the above text
> to collect ideas/comments and patches?
yes, of course.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Digikam-devel