[Kde-pim] Re: kdepim-4.6 ?

[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).

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.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110410/19380879/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/