[KPhotoAlbum] Thumbnail loading speed vs. size.

Henner Zeller h.zeller at acm.org
Tue Sep 2 17:22:00 BST 2008


Hi,
On Tue, Sep 2, 2008 at 5:05 PM, Risto H. Kurppa <risto at kurppa.fi> wrote:
> On Tue, Sep 2, 2008 at 5:34 PM, Henner Zeller <h.zeller at acm.org> wrote:
>> Hi,
>>
>> -- 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
>
>> 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 ;-).
>
>
> I second this!
>
> Still the thumbnail generation is the slowest thing on KPA and makes
> me wait the most.

Note, that the _generation_ of the thumbnails is not affected much by
this, only the _loading_ or already generated thumbnails from disk.
This means, that paging through your thumbnail view should be smoother
with this change. The generation of thumbnails is maybe a bit faster
because it does not do compression; haven't measured that in detail,
though.

> Disk space is cheap, faster computers.. there's a
> limit in what's available and also the prices get high and there's no
> way to make a core2duo computer 10 times faster but doubling the disk
> space is not a big deal..

Speaking of more cores: since a month or so, we actually use multiple
cores to _generate_ the thumbnails (Jan implemented that). And in the
KPA sprint we already fixed the bugs it introduced ;-)
So generating should be sped up by about the number of cores (Loading
it from disk as well, btw. so the smoothness in paging is as well
affected by number of cores).
Another interesting part of that change is, that it now actually
generates all thumbnails for new images in the background.

-henner



More information about the Kphotoalbum mailing list