----------------------------------------------------------- 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 > >
