[Kde-pim] which akonadi is safe to use with KDEPIM 4.14.x? and some other things

[Milian Wolff]

On Tuesday 02 December 2014 21:00:00 Martin Steigerwald wrote:
> Hi!
> 
> I bet only 1.13 as the Qt5 in master one… would be incompatible?

Can't say whether Qt5 based master is incompatible, but I use 1.13 personally.

> I read about query optimization stuff being discussed and would like to try
> out latest fixes anyway.

I pushed all optimizations to 1.13. And considering that many people will 
stick to that version or follow-ups based on Qt4 for a long time, probably, I 
think it's worth to optimize that a bit further as well.

Christian also mentioned some optimizations in the kolab branches. I actually 
don't know where these branches can be found - Christian, can you tell 
something about that please?

> Any other branches you suggest? Maybe kdepim-runtime and kdepimlibs for
> additional fixes? I would keep the rest with Debian packages.

Just use the KDE/4.14 branches. If you want to optimize anything, that is the 
correct branch, I think. Forward-porting if needed is often pretty easy.

> I have *huge* POP3 mailbox (about 947000 *unread* mails) and a smaller only
> last 30 day IMAP copy of it (just about 51000 unread mails) as well on a
> Dovecot server privately and a *huge* IMAP Exchange mailbox as well which is
> good to test with a more crappy IMAP implementation that even challenges
> Trojita. Recently even that Exchange IMAP access works well enough to avoid
> the Outlook Web Access for mail, but there are still delays on switching
> between mails, which may or may not be fixable on client side.
> 
> The POP3 thing works quite well since the maildir synchronizing do not sort
> directory list fixes.

Cool. And I bet you can still find new optimization opportunities with such a 
setup. Any help is most welcome.

> I still want to try configuring in the old mixedmaildir mail archive, but
> last time I tried it consumed very much memory on initial syncing to the
> extent that it hogged the 8 GiB of RAM the laptop had back then in a way I
> thought I is better to stop this, before the machine becomes too
> unresponsive. Well now it has 16 GiB, so… that might be a nice case for the
> heaptrack thing Milian did.

Yep, that sounds like an issue. Give heaptrack a shot, I'd be interested in 
your findings. I forget if it's possible, but maybe you'll need to hack the 
akonadi source code to start a resource under heaptrack. Afaik there's so far 
only hard-coded support for valgrind and gdb, but maybe I'm mistaken. Sadly 
heaptrack cannot (yet?) runtime-attach to a process.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de