KConfig

[Waldo Bastian]

On Friday 10 January 2003 01:50, Benjamin Meyer wrote:
> On Thursday 09 January 2003 12:31 pm, Waldo Bastian wrote:
> > On Thursday 09 January 2003 16:03, Benjamin Meyer wrote:
> > > A quick browse through: ~/.kde/share/config/ contains
> > > quite a bit of settings the vast majority of which are default values.
> > > So making KConfig only save when the value is not the same as the
> > > default value would be a good thing.
> >
> > It's a bit hairy, since the default value is only provided at read-time.
> > We would have to convert it from its C++ type to a string in the read
> > call so that we can compare it later on in the write call. I don't mind
> > doing that, but I doubt if it is going to be any faster.
>
> Having to convert to a QString every time might even make it slower.  Would
> you really have to convert it?  I don't know the inners of KConfig, but
> can't you for example simply save the default value in its native value so
> that it could be compared later?

Let me explain:

The entry on disk looks like:

Color=#345678

The read call looks like:

QColor defaultColor = Qt::Blue;
myColor = config->readColorEntry("Color", &defaultColor);

The write call looks like:
config->writeEntry("Color", myColor);

KConfig internally stores in KEntry (See kconfigdata.h, basically a QCString) 
indexed with KEntryKey. You can have 1 KEntry for the actual value and 1 
entry for the default value.

To store the hard-coded defaults in the internal representation, one has to 
take the &defaultColor argument passed to the readColorEntry, and convert it 
to "#0000FF" and then store it in the map with KEntry entries.

The extra processing in the readEntry calls is going to make things slower. 
(CPU bound, slight increase in memory usage)

Is it going to be any faster? 

The reduced file-size will make some difference but I don't think that the 
size itself matters too much, disk I/O throughput speed is rather high and is 
done in blocks anyway, it's seek time that is slow. So I don't think you will 
get much speedup unless you can either eliminate the file completely, or 
reduce the numbers of (non-contiguous) blocks the file occupies on disk.
Looking at my config files I doubt either will be the case.

Cheers,
Waldo
-- 
bastian@kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian@suse.com