[Kde-pim] Profiling kmail: IdentityManager

[David Faure]

I used callgrind on kmail and found something interesting.

Every call to StringUtil::emailAddrAsAnchor (36 calls in my short run)
creates a KIdentityManagement::IdentityManager instance, which triggers
Kdelibs4ConfigMigrator in the constructor, which ends up triggering 
reparseConfiguration in the framework integration plugin. That's 36 times 
reparsing the same file for nothing (because surely migration only happens 
once).

I fixed Kdelibs4ConfigMigrator to only trigger a reparse if needed, and I fixed 
IdentityManager to only do this once, but this again makes me wonder: 
why isn't KIdentityManagement::IdentityManager a singleton?
I regularly hit performance issues due to the fact that every little bit of 
code which needs identities, has to create an IdentityManager 
first. Should we make it a singleton, or should we keep trying to make it 
"quick to create", something which seems to regularly fail?
(see https://git.reviewboard.kde.org/r/126703/ for the last time I hit a 
performance issue in that constructor)
In Qt, for a class to be "quick to create", it shares an underlying singleton 
for the Private class (see QMimeDatabase, and many others). The current
approach for IdentityManager (quick until someone adds some slow code
to the constructor) doesn't seem to work very well.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/