Re: bring speed back into KConfig

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 a=
nd
> > 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 t=
hat
store config files in some sort of repository. Just an example: cvs on linu=
x =

dislikes a directory structure created with the windows version of cvs.

Any program that reads a text file could be capable of handling various lin=
e =

styles and encodings.

Please also add or retrain the capability of handling BOMs (Byte order mark=
s).

> > Again: the use of mmap() caused exceptions in one network filesystem (s=
mb
> > 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 cat=
ch =

handler for it).

J=FCrgen