[Kde-pim] Akonadi mail performance outlook

[Christian Mollekopf]

On Friday 16 May 2014 21.36:27 Cédric Villemain wrote:
> > > And I don´t think this limitation is needed cause of database
> > > locking, clicking on the message just reads it for display. I don´t
> > > think that synchronizing the folder needs to lock out read access.
> > > At some time message read flag may need to be updated, but I don´t
> > > see why this can´t be happening asynchronously.
> > 
> > Database locking isn't the problem, or at least that should be
> > solvable.
> > 
> > The only thing we do need is a write lock during a sync on a
> > collection level (for consistency during a sync).
> 
> Can you elaborate the point about consistency and write lock ?

Note this is not about database consistency.

I assumed that a collection is locked during the item synchronization, but 
that is not actually the case. Instead items can be freely modified or created.
In the worst case, if an item is modified while a sync is in progress, this can 
result in a conflict that can be detected due to the item revision. 

So the write lock should not be required, and I see nothing blocking us from 
being able to read truly asynchronously from the server.

What I think would be required is the data-loading part of the application 
i.e. ETM to fetch data from the cache only, but still trigger the loading of 
messages if not available (otherwise i.e. online imap doesn't work where not 
all data is in the cache and we rely on the on-demand loading).

Additionally the resource scheduler (which is the part that currently only 
allows one task to be running at a time), should at least allow single item 
retrieval jobs while another task (i.e. collection sync) is running.

So:
* the ETM should use cacheOnly, but the on-demand loading should still be 
triggered asynchronously. This way the job finishes quickly, and missing data 
will appear in the model as it becomes available.
** For the ETM we should probably also use a second session, so even if 
another job is blocked, the ETM continues to load data quickly.
* The resource should retrieve individual messages immediately from the 
server, even when a collection sync is in progress. This ensures fetching a 
single item is not blocked by a background sync that potentially takes very 
long.

Cheers,
Christian
_______________________________________________
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/