bring speed back into KConfig

[Jakub Stachowski]

Dnia piątek, 18 kwietnia 2008, Jakub Stachowski napisał:
> Dnia czwartek, 17 kwietnia 2008, Olivier Goffart napisał:
> > Le mardi 15 avril 2008, Dirk Mueller a écrit :
> > > Hi,
[ ... ]
>
> I did some more optimizing to  minimize copying data around. Instead of
> using QByteArray everywhere I added class BufferFragment with very similar
> (bare minimum used by parser) API, but operating on allocated earlier big
> buffer. like left(), trim(), mid(), etc. are only pointer and int
> operations.
>
> Results:
>  - 500x parsing of kwin.notifyrc takes 1.3s instead of 5.8s
>  - KConfig from KDE3 takes 1.4s
>  - kconfig unit test pass
>
> BufferFragment class contains very short functions (most of them 1-3 lines)
> that could be inlined, so all definitions are in header file. Is it OK or
> separate .cpp file is necessary?

How nice to see traffic on kde-optimize again :-)
Here is second version of the patch with fixes to address comments:

Dirk Mueller:
a) I agree with Oswald that if reading whole file in one go might kill the 
app, then storing all parsed keys in memory will definitely do it. 
b) I added some comments to class and more interesting functions
c) OK, implicit conversion changed to toByteArray() function

Oswald Buddenhagen:
- I don't care one way or another about spaces around operators, but KConfig 
has them so I changed my code to match it.
- Changed BufferFragment& inout parameter to FragmentBuffer*

Lubos Lunak:
- Whole BufferFragment class got dumped into kconfigini_p.h and is now part of 
KConfigIniBackend
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kconfig-opt.patch
Type: text/x-diff
Size: 12416 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20080419/d76b74a5/attachment.bin