[KPhotoAlbum] Performance tuning..

[Robert L Krawitz]

   Date: Sat, 11 Feb 2006 12:43:42 +0200
   From: "Risto H. Kurppa" <risto.kurppa at gmail.com>

   You're doing good work - if it all works..

   I'm the guy with the pathetic 45000 image database and speed - I'd
   like to see it more..
   I'll wait for Jesper's opinion about your suggestions / fixes and wait
   for the next snapshot to see if something really has happened..

   Keep Going!

I'm reasonably confident in the patches I've sent in thus far.  The
cache stuff is going to take a bit more investigation (I have a
prototype that thus far seems OK, but I haven't exercised it
thoroughly).  It won't have quite as much payoff, although it will
make the program feel a lot more responsive.

Another thing I notice last night is that applying filters is
noticeably slow -- if I'm at top level (with 11000 images) and select
a grouping that has only 7 images in it, it takes a few seconds (on an
1800 MHz processor) for the selection to happen.  I don't think that
this is quadratic in the number of images, but it may be related to
the number of images and number of categories with a fairly large
constant.  It looks like it's somewhere in the
XMLDB::XMLDB::Classify() and ImageSearchInfo::match() code path.

   On 2/11/06, Robert L Krawitz <rlk at alum.mit.edu> wrote:
   > There's another spot that I think is ripe for some performance tuning
   > work: the thumbnail cache.
   >
   > void ThumbnailView::ThumbnailView::reload( void )
   > {
   >     pixmapCache().clear();
   >     _selectedFiles.clear();
   >     updateCellSize();
   >     repaintScreen();
   > }
   >
   > This is called out of MainView::reloadThumbnails(), which is called
   > whenever the thumbnails are shown, the date range changed, images are
   > reconfigured, and a few other cases.  There certainly are situations
   > where the entire thumbnail cache needs to be cleared; the thumbnail
   > size changing is of course one of them.  However, in many
   > circumstances there's no need for the thumbnail cache to be cleared at
   > all (e. g. when the date range is changed, when the thumbnails are
   > displayed), and others where only a few thumbnails need to be flushed
   > (thumbnails are rotated or drawn on, for example).  Even with my
   > improvements there's a huge performance difference between redrawing
   > cached thumbnails and loading the thumbnails to begin with.  I've
   > prototyped a change whereby the pixmap cache is only cleared in some
   > cases (where the thumbnail size is changed or where images are
   > reconfigured) and it's a lot faster.
   >
   > Another optimization that might be worthwhile would be to have a
   > background thread that gradually loads thumbnails whenever nothing
   > else is going on.  For the common case where someone loads a large set
   > of images and then gradually scrolls down this would make the
   > application much snappier.
   >
   > --
   > Robert Krawitz                                     <rlk at alum.mit.edu>
   >
   > Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
   > Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
   > Project lead for Gutenprint   --    http://gimp-print.sourceforge.net
   >
   > "Linux doesn't dictate how I work, I dictate how Linux works."
   > --Eric Crampton
   >
   > _______________________________________________
   > KPhotoAlbum mailing list
   > KPhotoAlbum at mail.kdab.net
   > http://mail.kdab.net/mailman/listinfo/kphotoalbum
   >
   >

   _______________________________________________
   KPhotoAlbum mailing list
   KPhotoAlbum at mail.kdab.net
   http://mail.kdab.net/mailman/listinfo/kphotoalbum