Resedit (Was: Proposal for KControl)

[aleXXX]

On Monday 01 July 2002 23:53, Guillaume Laurent wrote:
> On Monday 01 July 2002 22:36, aleXXX wrote:
> > ...and it will slowdown config file parsing and app startup (we read more
> > than 10 config files for every app that starts).
> > Ok, the parsing of a line stops after a "#" was found, but nevertheless
> > it has to run over all the bytes, and such a change would more or less
> > double the line number of each config file, wouldn't it ?
>
> Even if it would triple or quadruple it, you'd still wouldn't notice a
> difference.
>
> A few months ago I benchmarked the compilation of a fairly large (in the
> 100 KLOCs range) C++ library, once with documentation (doxygen style) in
> the headers, and once without. On a 20mn compile (dual P-III 900, SCSI,
> 256MB), the difference was under 1 second.
>
> Check it for yourself. Suppose all your config files total 2000 lines, say
> 80 chars each, half of which begin with '#'. So that's 80,000 chars to
> scan. scanning an std::vector<char> of such a size takes 30ms on my machine
> (PIII 600), 10ms if I compile with -O2.

Ok, so imagine a 200 MHz CPU and you get in the range of 0.1 s.
0.1 s startup time more e.g. for konsole is something which shouldn't be 
ignored.

Well, config file reading is an important issue in startup time of KDE apps.
Anything which might slow it down should be handled very carefully.
The effect which doubling the size of the config data for every app has 
should definitely be measured on a slow system before it is added to kdelibs.

Probably the increased size if the config files also won't speed up the 
process of mmapping them into memory, but I don't know, I didn't measure.

As you can see on the dot, actually the only real problem KDE has right now 
is speed and memory consumption (ok, mainly speed).

Bye
Alex