[Kde-pim] Akonadi mail performance outlook

[Daniel Vrátil]

On Thursday 01 of May 2014 21:50:40 GEO wrote:
> Hi,
> 
> I am using Akonadi for my mail setup now more intensively than every before
> and have an mail account with over 10 000 mails atm. This is enough to see
> some performance issues associated with Akonadi.
> Here are my top 3 (in the following folder sync means when you have just
> created your account and you click a folder):

Hi,

> 1.) When configuring an imap account (gmail in my case) and you click a
> folder in kmail, the sync will begin. (No special settings, just created
> the account with the account wizard). If you click another folder now,
> nothing happens, it will wait till the initial folder is completely synced.
> This is not exactly asynchronous and should be addressed.

This is a known problem with session blocking. Not sure how to solve this yet, 
sorry.

> 
> 2.) Syncing a folder begins with the oldest messages. If the account is big,
> it takes some time till you reach the latest message. In reality, you might
> be more interested in you latest mails at first, so doing that in reverse
> order would allow you to make use of kmail instantly, without waiting for
> the sync being complete.

That's very hard, because in IMAP, you can only query sets of items in 
ascending order (1 being the oldest message), so we can only query 1:* (from 
first to last), not *:1.

However you only do the complete sync once, after that it's only incremental, 
i.e. IMAP resource only requests changes since last check (not on Gmail, that 
has to check all emails in the folder, because their support for this feature 
is broken, but I'm working on it).

> 3.) During the folder sync, it is nearly impossible to click a message in
> the folder. You will have to wait extremely long. This should not be the
> case. Fetching a message content should be completely independent from
> syncing the folder and should only be limited by physical things like
> connection speed, disk i/o, cpu load, ram etc.

It cannot be independent, because in the background it shares the same 
database, where database locking and long transactions (known problem, again)  
lead to retrieval operations taking long time.

> 4.)  Please implement parallelism in Session and Resources, to avoid the
> authentication dialog blocking all Akonadi ressources, if one server does
> not respond.

That is a hard problem, but something we indeed want to have at some point. 

> The idea behind this is, to be able to configure your account and start
> being productive right away, without having to wait, till akonadi has
> cached everything. The only component that works like this atm, is sending
> mails, that works right away, but for everything else you would want to do
> (read mail and respond) etc. you have to wait.
> I have not tried mail filters yet during initial sync, but I think they will
> work in parallel.

Local mails work on top of Akonadi cache, so the mails will first appear in 
your INBOX and then will be processed by mail filter and moved to respective 
filters.

> I know that implementing this might not be trivial, it would be a long term
> wish though. It has nothing to do with criticism, in fact I am a fan of
> akonadi and I respect the enormous efforts of the devs.
> 
> Once Akonadi is up and running, everything is pretty fast in my experience,
> not even trojita is faster. But for initial setup it is still lacking in
> terms of  the time you have to wait to start working.
> I know, some are of the opinion that you do not recreate your mail account
> every day, but I think, especially for big account, addressing the first 3
> issues would really be cool.

Some of the things you suggested (mostly the session parallelism) would also 
solve other problems, so we really wan to have them, but it's still a long 
way.


Cheers,
Dan

> 
> Greetings,
> 
> GEO
> _______________________________________________
> 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/

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140502/8ec638ae/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/