performance problems with recursive view and filtering

[Arnd Baecker]

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)

    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.

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

Best, Arnd

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/1/4, Arnd Baecker <[hidden email]>:

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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel