[KPhotoAlbum] Performance comparison with Digikam

[Robert Krawitz]

I compared the same 10840 images loading into Digikam.  Digikam took
much less time until the UI was usable (about 90 seconds on the SSD,
vs. 213 or seconds best case for us and 270 with the I/O tuning we've
done).  It appears that Digikam did a quick scan for dates during that
interval, so it was able to read less data.  However, Digikam took
about 690 seconds total to build its thumbnails (which are rather
smaller than what I use), with heavy CPU consumption, whereas we have
very little penalty at worst for building thumbnails.

On the HDD, Digikam took about 340 seconds to do the initial scan
(vs. 900 for kpa) and 78'41" (4721 seconds) to build the thumbnails.
The IOPS is high (150-200/sec), so obviously it's doing very small
operations.  It uses an SQLite database to store the thumbnails, and
based on how small the journal file is (it never exceeds 11K) and the
fact that it's making a lot of fdatasync() calls it appears not to be
using a transaction.

It is possible to move around in the thumbnail view, but you're moving
around somewhat blindly until it starts generating thumbnails for your
viewport (it does start right away, but the generation process is very
slow).

Digikam was also much slower at scrolling through thumbnails (loading
the next page of thumbnails takes noticeable time) and its viewer,
despite not being full screen, was also much slower; I could get ahead
of it with individual presses of the spacebar which I can't with kpa.

The only way we'd get the new image load time down would be to skip
the MD5 hash and thumbnail build; we'd essentially have to load the
EXIF data first and then generate the MD5 and thumbnails later, which
would be a fundamental change in how KPA operates.

In a nutshell, KPA and Digikam have made different design decisions.
While I wouldn't mind seeing the UI return more quickly, I do like
that when it does come back everything is fully ready and I'm not
operating in a degraded mode while other work is being done.
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton