[KPhotoAlbum] Performance problem with nested categories

Robert L Krawitz rlk at alum.mit.edu
Sat Dec 9 02:16:40 CET 2006


   From: "Jesper K. Pedersen" <blackie at blackie.dk>
   Date: Sat, 9 Dec 2006 01:43:20 +0100

   Why do you think hasCategoryInfo is expensive? It looks up an item in a map 
   O(logn) plus afterwards look another item up in a set (another map to be 
   technical), which is another O(logn).

It's probably not that expensive in and of itself (although it isn't
constant time, either); the problem is that it's being called so many
times.

   On Friday 08 December 2006 23:20, Robert L Krawitz wrote:
   | I have a database with about 17000 photos in it.
   |
   | If I select the folder "20d" (which has subfolders such as dcim,
   | dcim/100canon, etc.), it takes a very long time -- maybe 30 seconds or
   | thereabouts.  Selecting a leaf folder is very quick.
   |
   | I put some trace code in.  It looks like the implementation of
   | DB::OptionValueMatcher::eval() and its children (in particular,
   | ImageInfo::hasCategoryInfo) is very slow.  The trace I got looks
   | something like this:

-- 
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


More information about the KPhotoAlbum mailing list