[Kde-pim] KMail Memory Report

[Daniel Vrátil]

On Tuesday 18 of November 2014 13:07:06 Milian Wolff wrote:
> Hey all,

Hi,

> I played around with heaptrack [1] some more recently and looked at KMail
> again. See these reports:
> 
> 1) hotspots by peak memory consumption:
> https://userpage.physik.fu-berlin.de/~milianw/kmail.peaks.log
> 
> 2) hotspots by "merged" peak memory consumption:
> (this groups backtraces that point to the same leaf node, thus all
> backtraces that call e.g. QString::realloc are seen as one "peak". there
> algorithm currently does not take time into account properly though, which
> is why the results might be wrong. still interesting imo)
> https://userpage.physik.fu-berlin.de/~milianw/kmail.peaks.merged.log
> 
> 3) hotspots by number of calls to malloc & friends:
> https://userpage.physik.fu-berlin.de/~milianw/kmail.allocations.log
> 
> 1) and 3) I showed you before, nothing much has changed there. Akonadi::Item
> is still large and KMime::HeaderParsing still inefficient. I proposed some
> ideas before on how to tackle these issues, and I still plan to do that
> eventually.

\o/ This needs some love indeed and it would be nice to get the improvements 
to 4.14 too (should be OK as technically, they are bug fixes).

> Are there by now news on the improved streaming interface to
> Akonadi which gets rid of all the silly string parsing etc.?

Akonadi Framework will use a binary protocol. The obvious candidate is 
QDataStream, but I haven't done any benchmarks or tests to see how well it 
will work for us. Also the protocol won't be part of public API anymore, which 
makes it easier to optimize (or replace completely) at any point.

> But more interesting today is imo 2) as it spots some issues in the public
> API. I hope these things get fixed before a first KF5 based KDEPIM is
> released with ABI stability guarantee: Don't use QList by default! KDEPIM
> source code and public API is riddled with this container class. But read
> this e.g.: http://marcmutz.wordpress.com/effective-qt/containers/

Thanks for the link, interesting reading.

> QList should not be your container of choice **by default**!
> 
> Why? Take a look at 2) and search for QListData::detach_grow.
> KMime::Types::Mailbox, ::AddrSpec, ::Address, ... etc are all larger than
> sizeof(uintptr_t). Thus QList will allocate each individual Mailbox entry on
> the heap! Using QVector and marking the Mailbox as Q_MOVABLE_TYPE will make
> this much more efficient (better cache locality, less calls to malloc
> calls, less chance of fragmentation issues).

I assume this also applies to Akonadi::Item::List and 
Akonadi::Collection::List?

> Please take this into account in the current effort of creating a KF5 based
> KDEPIM.

This changes can be done already now in master, as master is KF5 and we can 
break stuff there (yaaay!)

Thanks for the analysis!

Daniel

> 
> Cheers!
> 
> [1]: http://quickgit.kde.org/?p=scratch%2Fmwolff%2Fheaptrack.git

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20141118/459ba1e8/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/