[KPhotoAlbum] Startup speed issues

[Lars Clausen]

My use of KPA has been somewhat curtailed by the slow startup -- it's
really hard to use a small break to tag a few images.  So I did an
analysis of the startup.  I have a collection of almost 17000 images and
50 videos, using the SVN version of KPA from 8/10 2006 (revision
593576).  This sounds very similar to bug #126506, which doesn't seem to
have been fixed,  My speeds are:

Splash screen appears: 0:05
End of "Loading Main Window": 1:25
End of "Searching for New Images": 2:05
Main window appears: 2:40
Image list appears: 3:45

The discussion of the bug back in the end of May indicated that the
index.xml file was to blame, but didn't give any indication of how to
fix it without losing all information in it.

After taking away my index.xml and building a new one, the times look
like this:

Splash screen appears: 0:05
End of "Loading Main Window": 0:10
End of "Searching for New Images": 0:55
Main window appears: 0:55
Image list appears: 0:55

This is obviously a lot better, now I just need a way to transfer over
the old tags.  Doing an export doesn't seem to get me all the info I
need, is there another way?  I can post/mail the index.xml file if it
might help.

Poking a little further, it seems that the number of tags involved makes
a big difference.  I added to all pictures a Person tag, a Location tag
and two Keyword tags (all the same), and now startup times are:

Splash screen appears: 0:05
End of "Loading Main Window": 3:30
End of "Searching for New Images": 5:15
Main window appears: 6:50
Image list appears: 9:50

So the startup time is directly proportional to the number of tags
assigned to pictures, it seems.  This is all with a non-DB enabled
version, since the DB isn't as I understand it stable yet.

Seeing as how the "Searching for New Images" part takes about 80% of the
startup time with a "good" index.xml, here's an idea for reducing it:
Keep track of when leaf directories have been modified, and if a leaf
directory hasn't been modified since last save, a) there's no new images
in there, and b) there's no new subdirectories in there.  Thus it
doesn't need to be scanned.  In my case, this would cut the number of
inodes queried from about 17000 to about 250.  

-Lars