[Kde-pim] Re: [PATCH] Increase responsiveness of PIM apps

[Volker Krause]

On Friday 31 December 2010 08:37:26 Tobias König wrote:
> the attached patch changes the behavior of EntityTreeModel in LazyPopulation 
> mode, which is used for nearly all PIM applications currently.
> The current behavior of the ETM is to connect against the 
> ItemFetchJob::itemsRetrieved() signal and inserting the new rows immediately 
> into the model. For larger folders this will cause multiple rowsInserted() 
> signals to be emitted, which results in multiple resets of the above proxy 
> models and time consuming updates in the views.

Note that those proxy model resets are specific to the grouping/threading models 
in the mobile apps and can probably be avoided in many cases. This does not 
happen in e.g. desktop KMail afaics.

> This patch changes ETM to wait until the ItemFetchJob has finished and 
> inserting all items into the model in one go.
> While this will stall the point in time when the first item is visible in the 
> view, the view is immediately responsive once the items have been populated.
> 
> Loading a local folder with 1400 messages in kmail-mobile with the 'old' ETM 
> will show the first messages after ~2 seconds but the listview can't be used 
> (e.g. scrolled or clicked on an item), because there are consecutive 
> rowsInserted() signals emitted from the model which causes to reset the proxy 
> models and the view ~20 times. So the listview can't be used for the next 20 
> seconds (setup: single core CPU with 1500 MHz).
> 
> Using the 'new' ETM, the first messages are shown after ~3 seconds (just a 
> feeling, difficult to measure exactly), but then the listview is responsive 
> immediately and can be scrolled right now.
> 
> So the question is whether the initial delay (until the first message is 
> shown) can become too large to draw the advantages of the reduced 
> rowsInserted() signals void. Can somebody with large online IMAP folders check 
> how this patch works for him?

>From observing the loading behavior in desktop KMail for some of my 20+k folders, 
I have the feeling (not tested yet) I'll get too large. I'm usually reading a few 
mails already in those while the loading finishes in the background (which works 
fine since the reader uses a second session).

Since ItemFetchJob uses a timer to do the grouping for its received signal 
(currently 100ms), it might be possible to increase that (or even dynamically 
increase it, starting small to have initial data quickly) to find a compromise 
between initial wait time and overall cost.

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/20110103/8ccd7de0/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/