Frustrating to use KMail with Akonadi 5.14.1 (20.04)

[Martin Steigerwald]

Hi!

This is a plea to any KDE developer who feels capable and willing of 
doing so, to look at whether it would be possible to make Akonadi great… 
not again, but for the first time… or whether it would be wise to finally 
start over with a new approach.

It easily takes a minute or longer  to synchronize a mail folder with 
just a few thousand mails. It is much, much, much slower than with KMail 
with Akonadi 19.08. During that time Akonadi does not respond to KMail 
requesting the payload of a mail I click on.

Which means: I have to wait a minute, sometimes longer for being able to 
read a mail in a folder I just selected.

This

[Akonadi] [Bug 422336] kmail: the access and reading of the received 
messages is often very slow

https://bugs.kde.org/422336

together with

[Akonadi] [Bug 367892] New: During folder synchronization Akonadi blocks 
out other operations like deleting or viewing mails.

https://bugs.kde.org/367892

and

[Akonadi] [Bug 334216] New: synchronizes folder with filesystem after
downloading and filtering mails needlessly

https://bugs.kde.org/334216

makes using KMail a really frustrating experience.

And then there is also this:

[Akonadi] [Bug 422490] New: maildir gets stuck on synchronizing a folder 
with 72 messages

https://bugs.kde.org/422490


I am again pondering to just switch away from it despite having years of 
mail history in it, a ton of contacts and years of calendar items.

Its all so nice to have KDE Itinerary and all those new features, but if 
the basic operation of KMail is such a wait for Akonadi game it is 
really not much fun to use it anymore. I am using it on a dual SSD BTRFS 
RAID 1 and at least some Sandybridge CPU. I know that is not the most 
recent CPU, but it certainly has more than enough power for the task at 
hand if it is done in an efficient way. But Akonadi does not appear to be 
efficient. Not at all. Instead it still appears to be doing a huge ton of 
needless work due to being designed in the way it is.

It was not great to begin with. It got a bit better, but now it got 
worse again.

I really think it is important to focus energy on making it work 
reliable and *never ever* let the user wait for a minute or longer to 
display a mail. If you like to have unhappy users, do that.

I would do it, if I would find myself able to do so without first learning 
C++ and refreshing my C skills and also really understanding how Akonadi 
works. Fixing this up is most certainly no low-hanging fruit. Otherwise 
I bet someone would have done it already. And I know, some brave 
developers like Daniel, but also other put quite some effort into it.

Added to that Akonadi occasionally crashes for me since KDEPIM/Akonadi 
19.08. That got a bit better with 20.04, but it still happens.

I may try to switch everything to Evolution. I use it at work. It has 
its on set of usability issues. But at least it works:

- No crashing.
- No waiting.

It *just* works. Granted that is with Evolution EWS and I did not yet 
test local mail storage, but I would not expect it to be any slower. 
There sometimes some delays with Office 365 at work¹.  But then in 
Evolution just the operation at hand is waiting and I can still use it 
for something else. It may even pile up several operations, but so far 
it always completed them just fine *while* still responding to user 
requests.

I thought that was exactly what Akonadi was supposed to achieve. To 
decouple all the heavy lifting from the application and make it not 
block on background operations. Yet that is where Akonadi still falls 
short, big time. I don't know how this Evolution data server thing is 
implemented, but I know this thing works.

[1] As far as I read in some Akonadi EWS related bug report Microsoft 
does even rate limit stuff to lessen the resource usage on their Office 365 
cloud – i.e. tell the application to try again later in cases of 
overload (seriously!?). I would not be surprised if that would be the 
case.

Thanks,
-- 
Martin