[KPhotoAlbum] Startup performance

[Tobias Leupold]

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.

Cheers, Tobias

Am Montag, 12. Oktober 2020 15:06:34 CEST schrieb Robert Krawitz:
> We're running out of obvious low hanging fruit.  I don't like 
> startup taking 8 seconds even with a
> big database (it's a bit of a barrier to starting up kpa on the 
> spur of the moment), but without
> more significant changes, we're pretty much not going to get 
> much faster than we are today.
>
> Currently, the breakdown broadly looks like:
>
> Load database: 80-85%
>   Load image files (createImageInfo): 45-50%
>   readNextStartOrStopElement: 35-40%
> Load thumbnail cache: 5%
>
> The remainder is all in _dl_runtime_resolve_xsave, which is 
> untraceable so far as I can tell.
>
> Within createImageInfo (treating that as 100%), 
> possibleLoadCompressedCategories is about 45%,
> dateTimeFromString about 11% (yes, even after the work I did 
> there), getAttribute about 10%, and a
> lot more between 3 and 8% scattered all over the place.  I was 
> hoping that by replacing getAttribute
> (which is a linear scan of the XML attributes) with looping 
> over them I'd save some of that, but it
> hasn't worked out thus far.  Within 
> possibleLoadCompressedCategories, about 25% is getAttribute, a
> little less is addCategoryInfo, 10-15% is escaping attribute 
> names (yes, even after that routine
> caching escaped names), and it goes down from there.  So, 
> pretty slim pickings.  Caching escaped
> attribute names higher up does give maybe 3%, at the cost of 
> duplicating work (inlining part of
> escaping attribute names might work better).