kconfig and kde global config files

Aaron J. Seigo aseigo at kde.org
Sat Mar 4 03:36:28 GMT 2006


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

additionally, i noticed that we look for -both- kdeglobals and 
system.kdeglobals. i was completely unaware of system.kdeglobals. where does 
that come from? and do we need BOTH kdeglobals and system.kdeglobals? should 
we keep them in kde4 just for backwards compatibility (at the cost of some 
more stat'ing about on disk)?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060303/e594c9aa/attachment.sig>


More information about the kde-core-devel mailing list