Re: bring speed back into KConfig
Jaroslaw Staniek <[email protected]> Mon, 21 Apr 2008 12:54:05 +0200
| Newsgroups | gmane.comp.kde.devel.core,gmane.comp.kde.devel.optimize |
|---|---|
| Message-ID | <[email protected]> |
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)