Review Request 118587: Optimize KConfigIniBackend::parseConfig by reducing allocations.
David Faure
faure at kde.org
Fri Jun 6 11:59:30 BST 2014
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118587/#review59406
-----------------------------------------------------------
kdecore/config/bufferfragment_p.h
<https://git.reviewboard.kde.org/r/118587/#comment41361>
Why? Now it could clash with an application class BufferFragment, on a system without "hidden visibility". Or it might confuse gdb, even with hidden-visibility? not sure how that works.
kdecore/config/kconfigini.cpp
<https://git.reviewboard.kde.org/r/118587/#comment41362>
This isn't always the case though. kmail does that, yes, but e.g. kdeglobals doesn't.
Nor most desktop files, nor konquerorrc (except that some video player added per-file groups into mine!).
What do we lose if the config file has no repeated keys? Memory (the hash) and CPU (inserting and looking up into the hash), right?
I have a hard time being sure that the tradeoff is always in our favour.
- David Faure
On June 6, 2014, 9:31 a.m., Milian Wolff wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118587/
> -----------------------------------------------------------
>
> (Updated June 6, 2014, 9:31 a.m.)
>
>
> Review request for kdelibs and David Faure.
>
>
> Repository: kdelibs
>
>
> Description
> -------
>
> Optimize KConfigIniBackend::parseConfig by reducing allocations.
>
> Yet another awesome application of the Qt implicit sharing trick.
> Since config files often contain only few different keys and even
> value strings, we can share them. This reduces memory consumption
> and also speeds up parsing, as we do not have to allocate the
> duplicated strings, but can simply reuse the previous values.
>
> The most extreme case for this of my knowledge, is KatePart:
> katesyntaxhighlightingrc has more then 20k lines which triggered
> about 30k allocations on startup. With this patch applied, this
> value goes down dramatically. I added a simple static counter for
> the cache hit/miss ratio, which resulted in 5442 cache misses compared
> to 43624 cache hits across all KConfig files parsed by kwrite on startup.
>
>
> Diffs
> -----
>
> kdecore/config/bufferfragment_p.h 5a753ad
> kdecore/config/kconfigini.cpp 8ec43c5
> kdecore/config/kconfigini_p.h d7aa43e
>
> Diff: https://git.reviewboard.kde.org/r/118587/diff/
>
>
> Testing
> -------
>
> Unit tests all pass. My malloc tracer shows that the allocations are all gone.
>
> My malloc tracer showed before:
>
> 17421 allocations at:
> 0x7fee73692b97 QByteArray::QByteArray(char const*, int) /usr/lib/libQtCore.so.4
> 0x7fee73bb7cee ? /usr/lib/libkdecore.so.5
> 0x7fee73bb7fc4 ? /usr/lib/libkdecore.so.5
> 0x7fee73ba1320 ? /usr/lib/libkdecore.so.5
> 0x7fee73ba1731 KConfig::KConfig(QString const&, QFlags<KConfig::OpenFlag>, char const*) /usr/lib/libkdecore.so.5
> 0x7fee64830c06 KateHlManager::KateHlManager() in /ssd/milian/projects/kde4/kate/part/syntax/katesyntaxmanager.cpp:76 /ssd/milian/projects/compiled/kde4/lib/libkatepartinterfaces.so.4
>
> 12699 allocations at:
> 0x7fee73692b97 QByteArray::QByteArray(char const*, int) /usr/lib/libQtCore.so.4
> 0x7fee73bb7cd7 ? /usr/lib/libkdecore.so.5
> 0x7fee73bb7fc4 ? /usr/lib/libkdecore.so.5
> 0x7fee73ba1320 ? /usr/lib/libkdecore.so.5
> 0x7fee73ba1731 KConfig::KConfig(QString const&, QFlags<KConfig::OpenFlag>, char const*) /usr/lib/libkdecore.so.5
> 0x7fee64830c06 KateHlManager::KateHlManager() in /ssd/milian/projects/kde4/kate/part/syntax/katesyntaxmanager.cpp:76 /ssd/milian/projects/compiled/kde4/lib/libkatepartinterfaces.so.4
>
> These where the allocation hotspots number #1 and #3 respectively. With the patch applied, the two locations are not under the top 10 anymore.
>
>
> Thanks,
>
> Milian Wolff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140606/99f46e8b/attachment.htm>
More information about the kde-core-devel
mailing list