Frustrating to use KMail with Akonadi 5.14.1 (20.04)
martin at lichtvoll.de
Fri Jun 5 17:52:37 BST 2020
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.
[Akonadi] [Bug 422336] kmail: the access and reading of the received
messages is often very slow
[Akonadi] [Bug 367892] New: During folder synchronization Akonadi blocks
out other operations like deleting or viewing mails.
[Akonadi] [Bug 334216] New: synchronizes folder with filesystem after
downloading and filtering mails needlessly
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
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
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
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.
 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
More information about the kdepim-users