[Digikam-devel] performance problems with recursive view and filtering

[Gilles Caulier]

2008/1/4, Arnd Baecker <arnd.baecker at web.de>:
>
> Hi,
>
> 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
>        DigikamView::slotImageSelected()
>     take place.
>     Only at the very end
>        DigikamView::slotDispatchImageSelected()
>     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
>       AlbumLister::slotFilterItems()
>     which calls
>       matchesFilter
>     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.
>       Then
>          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.


yes

Should I open a new bug report with the above text
> to collect ideas/comments and patches?


yes, of course.

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20080104/56ece1dc/attachment.html>