Review Request: KConfigXT performance fix: no need to reparse when nothing to save

David Faure faure at
Thu Nov 17 15:41:32 GMT 2011

This is an automatically generated e-mail. To reply, visit:

(Updated Nov. 17, 2011, 3:41 p.m.)

Review request for kdelibs and Aaron J. Seigo.


Closing a kmail composer window takes a very long time, because it's calling writeConfig() on 7 kconfigskeleton objects (see KMKernel::slotSyncConfig), and each of them calls KConfig::sync() [that's ok, it doesn't do anything if there's no change to save, i.e. no dirty entry] followed by readConfig(), which calls KConfig::reparseConfiguration(). That's a lot of config file parsing, for a case where *nothing has changed*.

Looking into the history of the kconfigskeleton code didn't help finding out why writeConfig calls readConfig, this was added by Waldo in the initial code in 2003.

A real sync() with dirty entries triggers a reparsing (to merge changes on-disk with changes in memory), so it makes sense to propagate the changes from KConfig to the KConfigSkeleton member variables after a sync. But not when sync does nothing at all.


  kdecore/config/kconfig.h 51381ca 
  kdecore/config/kconfig.cpp fcf0ce9 
  kdecore/config/kcoreconfigskeleton.cpp f5dd4bf 



kdecore unittests pass. The testing of "closing a composer window" isn't fully fixed with this patch alone, kmail2rc is still reparsed because the kdeui code that calls revertToDefault on entries that are equal to the default value, makes the config dirty. This requires a different fix which I'll submit separately.


David Faure

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-core-devel mailing list