[Kde-pim] Re: kdepim-4.6 ?

[Volker Krause]

On Sunday 10 April 2011 18:52:34 Andreas Gungl wrote:
> 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.

Probably not correct, but based on the current implementation that's at least 
the expected behavior. But with Nepomuk disabled they shouldn't do anything, 
ie. not consume any CPU time.

> I only can imagine the whole thing should be faster without Nepomuk, as less
> work is to be done, isn't it?

Yes, in theory. However, there can be code that does not handle the missing 
Nepomuk case correctly and runs into D-Bus timeout scenarios for example 
(typically that means a freeze of about 25 seconds). This has gotten quite 
rare recently though. 

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

That would be most appreciated, I've written down a few things about the 
current database usage in the wiki, including pointers to the schema, the 
mysqld configuration and ways to access the db while Akonadi is running: 
http://techbase.kde.org/Projects/PIM/Akonadi/Database

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/20110416/c17caffa/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/