[KPhotoAlbum] Startup performance
Robert Krawitz
rlk at alum.mit.edu
Mon Oct 12 14:06:34 BST 2020
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).
More information about the Kphotoalbum
mailing list