bring speed back into KConfig

[Jaroslaw Staniek]

Jakub Stachowski said the following, On 2008-04-18 00:24:
> Dnia czwartek, 17 kwietnia 2008, Olivier Goffart napisał:
>> Le mardi 15 avril 2008, Dirk Mueller a écrit :
>>> Hi,
>>>
>>> the "knotify4 eats cpu" bugreport seems to be highly popular, so the
>>> reason for that seems to be the incredible performance loss in KConfigIni
>>>  due to the "kconfig refactoring branch" being merged last autumn by
>>> Andreas Pakulat.
>> Oh, i though it was a problem in the xine backend, which is why i did not
>> spend much attention to it.
>> I may have a closer look.
> 
> 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.

Cool.
I have question about using things like d->entryMap.keys() in 
KConfig::deleteGroupImpl(). Do we need to create the list at all?
Perhaps it's enough to have one common loop instead of two, with an iterator 
instead of foreach().

I've seen there may be more cases like this.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)