[Digikam-devel] [Bug 155097] New: performance problems with recursive view and filtering

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=155097         
           Summary: performance problems with recursive view and filtering
           Product: digikam
           Version: unspecified
          Platform: Debian stable
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: NOR
         Component: Filter
        AssignedTo: digikam-devel kde org
        ReportedBy: arnd.baecker web de


Version:           0.9.4 svn (using KDE KDE 3.5.5)
Installed from:    Debian stable Packages

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.