[KPhotoAlbum] Startup performance: the final frontier

[Robert Krawitz]

On Fri, 02 Jun 2017 10:27:01 +0200 (CEST), Harald Barth wrote:
>
>> Also, why do you frequently rebuild your thumbnails?  That's usually
>> something you do once and forget, unless you want to keep changing
>> your thumbnail size, which is going to be inefficient whatever you do.
>
> I suspect there can be made some optimizations in that corner. I see
>
> * Thumbnail rebuilding processes kicking in some time when I
>   don't quite understand why (on old pictures/videos which
>   already should have been processed a long time ago)

Full rebuild, or just a few?  If video thumbnail processing fails, I
see it trying to regenerate those thumbnails.

> * No good error handling if the thumbnail file can not be generated
>   because the file system credentials have run out.  It kindof seems
>   to assume that all I/O operations complete fast and with success.

That should be fixed; there are other reasons thumbnail file creation
can fail.

> * I have found empty videothumbnail files (an empty file does not
>   make sense, if there is no info, then you don't need to create the
>   file at all)
>
> * The 9000 video thumbnail files (of 900 videos) are all in one directory

I'd personally prefer just one thumbnail per file, stored in the
thumbnail cache file just like any other (at least as an option).

> Thumbnails are killing AFS I/O performance so bad that I made a link
> back to local laptop HD. Which of course means that thumbnails can
> no be shared between KPAs on more than one computer.
>
> Then I would like to have a setting "read thumb from image/video file
> thumb if available".

That's going to clobber your performance a whole lot worse -- you'll
be doing endless remote I/O calls on separate files, requiring extra
protocol exchange.

> Btw, it looks to me that kphotoalbum at startup every time traverses
> all directories and stat()s all files/images even if "search for new
> images at startup" is off. Is that necessary?

I just checked with strace on the current git master and saw no
evidence of that.
-- 
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