[Kde-pim] Re: kdepim-4.6 ?

[Torgny Nyblom]

(note to self, don't trust the laptops battery status icon on how much time or 
battery capacaty is left)

On Sunday 10 April 2011 09.42.03 Volker Krause wrote:
> 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.

The impression I (haven't had time to debug/try to fix yet) get is that some 
layer needs to fully retrieve the folder list before anything is shown in the 
GUI. Ie nothing is shown while the folder icon is in the "cricle" state, but 
then once the data is feed into the ETM (I guees here) mails start to appear 
and thanks to the resent change of ordering the unread mails appear quite fast 
and they are readable while the rest of the list is being populated. So my 
last beef is this "startup delay" on every folder switch. The reason I'm 
suspecting that some layer is fetching the entire folder is that the time it 
takes is way bigger then I expect it to take for MySQL to start delivering 
data after a query.

/Regards
Torgny
_______________________________________________
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/