kconfig and kde global config files

[Lubos Lunak]

On Saturday 04 March 2006 04:36, Aaron J. Seigo wrote:
> hi all...
>
> reworking kconfig i noticed that with each and every kconfig object we
> parse all the global kconfig files. it seems than an easy optimization
> would be to only parse the non-local-to-user global config files once
> per-app by caching the results in a static mapping in KConfig.
>
> this would mean some additional memory usage (we'd have one extra copy of
> the system-wide global file mappings) but we'd save on parsing those files
> and, more importantly probably, stat'ing all the KDEDIRS for
> config/kdeglobals and config/system.kdeglobals.
>
> however, this would mean that to see the results of  updated values in
> kdeglobals one would have to restart applications. since changes to system
> wide config files are relatively rare and many kconfig objects are
> long-lived (and others short lived) in apps it occurred to me that this is
> probably not a horrendous thing.
>
> i have done 0 benchmarking and am simply relying on the "common sense" that
> moving metal == slow. so, usual caveats about my common sense, yadda yadda
> ;)

 (0 benchmarking here too) I'd expect that the stats don't matter. You'd have 
to do them once at app startup anyway, then they'd be cached by the kernel 
and if done noticeably later they'd be lost in the noise anyway.

 As for optimizing KConfig, I wonder if the problem rather isn't the way 
KConfig works, QMap usage specifically. When I benchmarked the KDE startup 
last time it spent 10% time in KConfig (according to 
http://www.kdedevelopers.org/node/1661). Memory usage isn't that nice either, 
attachment shows memory usage reported by kdesdk/kmtrace for "kdialog 
--sorry" running (left number - malloc allocated size, right number - number 
of allocations) - KConfig accounts to about 150k. And that's for data out of 
which the majority probably isn't even used.

 (still 0 benchmarking mode) I wonder if and how big improvements could be 
brought by changing KConfig so that the INI backed could be rewritten to 
read-only mmap the files, implement readXYZ() by basically doing strstr() on 
the file for just parsing the one needed line and having a QMap (list, 
whatever) only for changed entries.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m.tree
Type: text/x-csrc
Size: 14508 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060304/47c91f4a/attachment.c>