[KPhotoAlbum] Startup performance

[Robert Krawitz]

On 10/12/20 12:45 PM, Tobias Leupold wrote:
> Hi Robert!
> 
> Thanks for your summary, your analysis and the great work you did to optimize KPA. The startup speed
> has been significantly improved since you started. And -- at least speaking me -- I wouldn't
> remotely be capable of neither finding the bottlenecks, nor fixing them.
> 
> As you said, most probably, further significant optimizations will only be possible via deeper
> changes in KPA's infrastructure.
> 
> But, as of now, I think we definitely can be contendend with the current state.

Yeah. I'd like to get my current MR merged (it's quite localized and does show meaningful
improvement) and then figure out where to go next.  If people hit local hot spots I can always look
at those, but otherwise I think it's pretty efficient now.  We could maybe look at detecting the
storage back end and auto-tuning file loading for it, but that's somewhat specialized.

I could see importing photos incrementally, allowing people to start working with them while more
are loading in the background.  Digikam does something like that, although last I tried the
appearance of being able to work with the photos was rather limited -- the UI was extremely slow
while photos were being imported.  Probably a more useful thing to do would be to have custom import
methods, where photos could be loaded from camera/memory card and put in the filesystem and imported
in one shot.  File importing is already a lot faster on even a comparatively modest machine (4-core
mobile Skylake HQ) than anything less than an NVMe drive, so you'd need a CF Express card to still
have a bottleneck (I should try it on my Ryzen 3900X which has a pretty good NVMe drive in it).
That's really only going to be noticed by very hard core sports/action photographers.  Thumbnails,
image viewing, and such are basically about as good as can be, limited by the I/O system; the
predictive loading works very well.

It really is the startup that's the most visible aspect of all of this.  Again, that either means
pretty fundamental changes in the storage backend, a faster XML parser, or maybe a way of bringing
up the UI while images are still loading (and since you're often going to want to look at your most
recent photos, not even very helpul).  If we stored photos in the database in _reverse_ order of
time, though, that might be workable (I'd love to have instant access to my most recent basketball
game while the rest of the file is being loaded).

But nothing really urgent.