[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KConfig again
From:       Mosfet <mosfet () jorsm ! com>
Date:       1999-05-17 6:29:47
[Download RAW message or body]

On Sun, 16 May 1999, Kalle Dalheimer wrote:
> pbrown@redhat.com wrote:
> > 
> > Mosfet and I were talking, and we made the hypothesis that most apps using
> > a KConfig object to a few initial readEntry()s, and then they basically
> > don't touch the KConfig object again until it is time to shut down (i.e.
> > destroy the object / save changes).  This means that keeping KConfig
> > entries around in RAM (cached) is rather a waste.  It would seem to make
> > more sense to read it dynamically off the disk when needed.
> > 
> 
> Of course, you can do that (and I would suggest using QCache as you go),
> but don't forget that you will have to reread all the configuration
> files in the hierarchy when you want to touch the object again. Thus you
> win some memory gain (just how much depends on the individual user's
> installation), but trade it for some performance loss, which again
> depends on the user's installation, but also hard disk speed usw.
> 

And also how KConfig is used. As I mentioned before, almost all apps read in
the KConfig items they want in their constructors and put them in local data
structures. They do not call readEntry a bunch of times throughout the
program. 

Then they may or may not write out they keys on exit. Many apps don't even do
this because kcm modules handle their config keys.... 

Why cache something that is not used for the vast majority of time for most
applications?

> Kalle
> 
> -- 
> Kalle Dalheimer              Contract programming for Unix
> kalle@dalheimer.de           Technical writing
> kalle@kde.org                Technical editing
> kalle@oreilly.de             KDE Developer (MFCH)
> mdalheimer@acm.org           It's open, it's source, it runs - must be
> KDE!
--
Daniel M. Duley - Unix developer & sys admin.
mosfet@kde.org
mosfet@jorsm.com

[prev in list] [next in list] [prev in thread] [next in thread]