bring speed back into KConfig

Juergen Pfennig info at j-pfennig.de
Mon Apr 21 13:45:48 CEST 2008


On Thu 17.04.2008, Dirk Mueller wrote:
> On Wednesday 16 April 2008, Juergen Pfennig wrote:
> > I also found (at that time) that the code was not perfectly optimized and
> > it was not capable of handling different line ending styles CR vs LF vs
> > CR LF and it did not handle various unicode encodings correctly.
>
> there is only one encoding: utf8, so this is lesser of a concern. the line
> ending style might be a new problem, but it certainly wasn't an isseu with
> kde3 :)

NO NO NO !!!!

Your assumption is that only kconfig writes to config files. But any user
or user program could do. What about running on windows? What about users that
store config files in some sort of repository. Just an example: cvs on linux 
dislikes a directory structure created with the windows version of cvs.

Any program that reads a text file could be capable of handling various line 
styles and encodings.

Please also add or retrain the capability of handling BOMs (Byte order marks).

> > Again: the use of mmap() caused exceptions in one network filesystem (smb
> > at that time). Please be very carefull before changing it.
>
> I'm also against adding mmap(), it doesn't seem to be a good idea and has
> too many drawbacks, especially iwth networked filesystems. However, a
> general parser speedup (in the style that qsettings e.g. did it, however
> that code is GPL, so we can't use it).

I did not say so, even the gnu c lib uses mmap today and this is correct. 
There was an implementation problem in the old code (W. Bastian added a catch 
handler for it).

Jürgen




More information about the Kde-optimize mailing list