[KPhotoAlbum] Startup performance -- next steps

Robert Krawitz rlk at alum.mit.edu
Sun Jun 4 18:35:18 BST 2017


I kcacheground kpa.  Lo and behold, I found that startup was spending
30% of its time in XMLDB::Database::Classify(), which runs through all
the images and videos for each category (keywords, places, people,
tokens, folder, media type, whatever else anyone has defined) and
determines what items of each category each image belongs to.

Making this into a nop (or short circuiting the inner loop, but
hopefully forcing it to do something) cut startup time for me from 17.5
to 13 seconds.  That's not quite 30%, but it's in the ballpark.

Now, the problem is, it's called three times.  It's always (it
appears) called from Browser::OverviewPage::updateImageCount().  It's
called twice from Browser::OverviewPage::activate() and once from
Browser::OverviewPage::OverviewPage().  The two calls to
Browser::OverviewPage::activate are in turn from
Browser::BrowserWidget::reload() and Browser::BrowserWidget::go().

It doesn't appear that there's any caching going on, so presumably
each call to updateImageCount() takes about 1.5 seconds, or maybe 9%
of the startup; if we could get that down to just one call, we'd save
maybe 17-18% of the startup time.

Now, on the other side: choosing the compressed format does save maybe
1.5-2 seconds (about 10%).  I'm going to kcachegrind it also to see
what that looks like.
-- 
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



More information about the Kphotoalbum mailing list