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

[Laurent Montel]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103166/#review8410
-----------------------------------------------------------

Ship it!


Ship It!

- Laurent Montel


On Nov. 17, 2011, 3:41 p.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103166/
> -----------------------------------------------------------
> 
> (Updated Nov. 17, 2011, 3:41 p.m.)
> 
> 
> Review request for kdelibs and Aaron J. Seigo.
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   kdecore/config/kconfig.h 51381ca 
>   kdecore/config/kconfig.cpp fcf0ce9 
>   kdecore/config/kcoreconfigskeleton.cpp f5dd4bf 
> 
> Diff: http://git.reviewboard.kde.org/r/103166/diff/diff
> 
> 
> Testing
> -------
> 
> 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.
> 
> 
> Thanks,
> 
> David Faure
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111123/d916f208/attachment.htm>