[KPhotoAlbum] Thumbnail Performance & Compatibility: ImageManager vs KIO

[Robert Krawitz]

On Sat, 29 Jun 2013 18:05:39 +0200, Johannes Zarl wrote:
> Hi,
>
> I'm wondering if it might be worthwhile to make use of KIO::PreviewJob in the ImageManager. I'm currently getting the feeling that doing all thumbnailing on our own creates a maintenance-burden that outweighs potential benefits of the current system.
>
> It's not that ImageManager is inherently doing things in a bad way, but together with the BackgroundJobs system it forms a complex entity that is IMO quite hard to debug, especially when it comes to performance problems.
>
> The way I see it, there are several nice things about the current system:
>  + Job priorities
>  + Animated video thumbnails

++ Performance, performance, and performance.  Oh, and performance while
we're at it.

The usual way of storing thumbnails as one image (png or jpg) per source
file is extremely inefficient.  Reading each thumbnail requires a
context switch into the kernel at least, and if the file isn't in cache,
at least one I/O operation (it may require reading the directory in
addition to reading the file from disk).  Rotating media can't sustain
much more than 100 IOPS, which limits how quickly kpa can display
thumbnails.  In addition, there's some overhead from decoding the image
files.  After this, kpa cached the thumbnails.  Before Jesper did this,
there was noticeable delay when displaying thumbnails -- it took a
couple of seconds to display each screen's worth of thumbnails, at least
until they were cached.

A lot of filesystems aren't very efficient with very large numbers of
files per directory, and with small files in general, compounding the
overhead.

The back end kpa uses for thumbnails, glomming large of raw bitmaps into
a few files, greatly reduces the I/O and decoding overhead.  Even on a
cold system, there's now no noticeable delay *whatsoever* when
displaying thumbnails.  This greatly improves usability of kpa.

(It also significantly reduces the storage required -- even though the
thumbnails are stored decoded, they take up fewer disk blocks, because
they avoid filesystem overhead for small files.)

It's very convenient to use a filesystem for storage, and in most cases,
it's the right thing to do.  It has interoperability advantages, as you
note, and it avoids the need for each program to implement its own
storage mechanism.  In some cases, though, the performance benefits of a
custom storage back end can be so compelling that tit's worth taking the
hit.  Databases are a common case.  Even databases that use the
filesystem normally implement their own structure on top of the
filesystem for efficiency (as opposed to using the filesystem to
structure records) -- and many databases have an option to go a step
further, using a raw disk partition.

There's no reason for kpa to go that far, but I think the tradeoff
Jesper made is a good one.

> OTOH, it has some disadvantages:
>  - no thumbnail sharing with other applications
>    (i.e. twice the time spent on thumbnailing)
>    This could also be dealt with by changing the ThumbnailCache.
>  - dependence on mplayer for video thumbnails
>    (mplayer is not shipped by every distro)
>
> Using KIO::PreviewJob would automatically make the cached thumbnails available for other applications (not just KDE), and at least provide a fallback for video thumbnails when mplayer is not available. It could also reduce the frustration for users who are beginning with KPA and have to wait for the thumbnail cache to be built.
>
> I guess there are several ways we could make use of KIO::PreviewJob in KPA:
>  a) Throw out ImageManager completely, use PreviewJob everywhere.
>  b) Use the scheduling of ImageManager to manage PreviewJobs,
>     use PreviewJobs for images and videos.
>  c) Like b), but keep the custom code for video thumbnails.
>
>
> Anyone has any thoughts on this?
>
> Jesper: you wrote the whole ImageManager code. I guess you had some reason not to use PreviewJob at that time? I don't want to go jumping out of the frying pan into the fire...

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

MIT VI-3 1987 - Congrats MIT Engineers 5 straight men's hoops tourney
Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
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