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

List:       kde-devel
Subject:    Re: KConfig again
From:       Kalle Dalheimer <kalle () dalheimer ! de>
Date:       1999-05-16 21:16:56
[Download RAW message or body]

Mosfet wrote:
> 
> 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?

KConfig already has a read-only flag, but nobody seems to use it. What
about making a KReadOnlyConfig class to make this more explicit.

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!

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