[Kde-pim] Re: kdepim-4.6 ?

[Andreas Gungl]

Am Sonntag, 10. April 2011 schrieb Volker Krause:
> On Thursday 07 April 2011 21:46:30 Joost Roeleveld wrote:
> > On Thursday 07 April 2011 16:38:09 Torgny Nyblom wrote:
> > > On Thursday 07 April 2011 16.18.17 Kevin Ottens wrote:
> > > [...]
> > > 
> > > > Could we get back on the KDE release train please?
> > > 
> > > +1 here,
> > > 
> > > I did a quick review of the bugs that came up in my search for kmail2
> > > and
> > > found one potential blocker that I added to the meta bug.
> > > 
> > > As for my impression the main issue I have is speed and I do not
> > > concider
> > > that as a blocker.
> 
> The interesting bit about the performance problem is that it's not
> universaly reproduceable everywhere. I'm using master with my production
> offline IMAP accounts, in total more than 250k mails. It's as fast as the
> pre-Akonadi KMail. I have debugged this with (IIRC) Till and Tobias
> before, who both had the performance problem, in these cases we tracked it
> down to:
> - Nepomuk queries per item in the header list (I had Nepomuk disabled at
> that point and thus wasn't seeing it), subsequently fixed
> - Expensive size hint calculation in the header list (already present in
> pre- Akonadi times btw), subsequently optimized and/or worked around by
> switching to a theme with uniform row heights (I wasn't seeing this
> problem due to using the right theme and not having folders with a lot of
> unread emails which due to thread-expansion in this case hit the row
> height size hint problem even harder).

FWIW I use the traditional header list (as in previous versions back in KDE3 
times). So I guess that's what you call uniform row height.
Further I have Nepomuk disabled in the KDE control center. Nevertheless there 
are akonadi-*-nepomuk processes active. Sometimes I get a popup telling me 
Nepomuk is disabled, but these processes stay alive. It looks strange to me, 
but I have no clue about the programming behind that. So I actually don't know 
if it's intended or a problem.
I only can imagine the whole thing should be faster without Nepomuk, as less 
work is to be done, isn't it?

> It looks like there are more problems like these, but as these example
> should show, just saying "it's slow for big folders" doesn't help us fix
> it, these problems occure due to specific conditions which are not
> universal and need to be identified. That's the hard part, and everyone
> can help with it.
> 
> > I had a quick look at that one and I too encounter it.
> > I put it down to using an IMAP-resource and/or incorrect start-up
> > sequence.
> > 
> > I get best performance from kontact 4.6 (beta...) when I can start
> > nepomukserver, then wait for it to be a bit more stabilised (eg. CPU-load
> > dropped) and then start akonadi...
> > 
> > Any idea why that might be?
> > 
> > Also, my akonadi.db is about 586M. That might also cause the problems?
> 
> The size as such is not a problem, my Akonadi data folder is 6.5G, the
> databasae alone is 2.5G. What's more interesting though is that you seem to
> be using Sqlite while I have MySQL. The transaction serialization we had
> to built in to make Sqlite work is known to block clients while e.g. an
> IMAP sync is going on. I have no idea if it really explains your
> performance problem, but it's one of the important differences. We have to
> collect those and verify one by one that they are not causing the problem.

I'm running Akonadi on top of mysql. If someone could point me to some 
information how to get access to the akonadi DB, that would be great. Usually 
I work with Oracle, but I'd be interested in just having a look at the data. 
Perhaps it might help to adjust some settings (memory for MySQL etc.).

Best regards,
Andreas
_______________________________________________
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/