[KPhotoAlbum] 45 000 images & KPhotoAlbum speed on Athlon 1GHz

[Robert L Krawitz]

   Date: Mon, 30 Jan 2006 19:28:11 -0500 (EST)
   From: "Walter Francis" <wally at theblackmoor.net>
   Cc: risto at kurppa.fi, kphotoalbum at kdab.net

   On Mon, January 30, 2006 17:17, Robert L Krawitz wrote:
   > Date: Tue, 31 Jan 2006 00:06:55 +0200
   > From: "Risto H. Kurppa" <risto at kurppa.fi>
   >
   >
   > Just to let you know what happens with a large database..
   >
   >
   > I finally managed to load (ie. I was able to track the damaged
   > jpegs) my photo collection into KimDaBa (using kimdaba-2006-01-14-noi18n ).
   >
   > Try 2006-01-28.
   >
   >
   > Sometimes it's very fast and does right away what I'm asking it
   > to do (a search, show thumbnails, whatever). But sometimes (with
   > no other resource monster programs running) it gets 'stuck'. It
   > starts to work on something and doesn't respond to anything. I
   > see that it's reading or writing (reading, I hope..) the hard
   > drive.  Usually the program takes some 370 (VM) + 200 (PM) Mb of
   > memory - but it's been up to 700 + something.. But it'll
   > eventually start working, if I'll just let it work (over the
   > night, for example..) long enoug.
   >
   > At least saving makes it stuck for a while.. Never actually measured
   > it precisely but I'd guess up to an hour or something
   >
   > Database size is about 21 Mb ( not compressed).
   > Processor is Athlon 1GHz
   >
   >
   > How much physical memory (which is likely to be much more
   > important here than the processor speed)?  What you're describing
   > sounds a lot like disk thrashing.  My guess would be that it
   > doesn't have very good memory locality, which is common with
   > database type things, and you've simply exceeded your physical
   > memory.  When that happens, performance falls off a cliff --
   > random memory access is about 100,000x faster than random disk
   > access.

   I have seen this too, but I can't put any reproduction steps behind
   it..  Kimdaba will suddenly stop responding and I'll look at
   gkrellm and the cpu is at 100%.  However, on my system it's
   definately not a resource issue, as I have an Amd65 3200 and 2G of
   ram.  There's no disk activity going on at all (I also have loud
   scsi drives).

   Seems to happen when going in and out of slideshow or doing a
   single view, not real predictable sometimes.

   I've been messing around for 5 minutes trying to reproduce it and
   can't seem to, but yesterday when I was tagging and messing with
   the exif view to reduce it to what I really want to see, it
   happened a few times on me..  It would stay in the 100%
   cpu/unresponsive state for perhaps a minute or so.

Now that you mention it, I did see something like this with one of the
older recent snapshots, and reported it (although it didn't hang for
half an hour -- 30 seconds or so was more like it).  It seemed to
happen coming out of the viewer most frequently, and I think Jesper
fixed it.  For example, right clicking on an image and doing Show
Folder or clicking on the beach umbrella.  That problem went away when
Jesper got rid of the QIconView.