[KPhotoAlbum] Thumbnail loading speed vs. size.

Henner Zeller h.zeller at acm.org
Tue Sep 2 15:34:17 BST 2008


Hi,

Right now, we try to follow the standard to store thumbnails in the
~/.thumbnails directory according to
http://jens.triq.net/thumbnail-spec/ .
This way, we're compatible with other applications that store thumbnails.

This standard requires, that the images are always stored in 'png'
format, but it felt slower than in earlier versions of KPA (back then,
it was stored in JPG format).

So I did some experiments with different formats, and included another
typical format in the unix world: PPM. The next table shows how long
fetching and decoding a thumbnail from disk takes on my machine (a
single core notebook):

-- ppm --
1 thread               avg/usec
file::retrieve()       1209.870

-- jpg --
1 thread               avg/usec
file::retrieve()       7853.912

-- png --
1 thread               avg/usec
file::retrieve()      15607.223

.. and these are the sizes:
Sizes   small   large
ppm     32654   131343
jpg      2976     8108
png     19165    68065

(and yeah, if anyone wonders why not use XPM - its about 10 times
slower than PNG and about 5 times the size of PPM).

So it seems that jpg is smallest and about twice as fast as decoding
PNG, but PPM is about 10 times as fast to decode, but about double the
size than PNG. This decoding usually is followed by a scale/rotate
step that takes another 4ms on my machine, so the final speed is not
10x, but still. The paging through thumbnails is much smoother with
PPM.

The question is, why PNG is soo slow to decode, I'd expect it to be
pretty optimized; maybe it is the libpng/QImage layering we have here
? Anyone wants to look in the code ?

I'd vote for disobeying the standard and use PPM instead of PNG by
default, but provide an option in the SettingsDialog that allows to
switch to PNG if the user wants to have it slow but compatible ;-).

cheers,
 -h



More information about the Kphotoalbum mailing list