Re: Unhappy with Akonadi

Hi,

I just want to share that my experience has been pretty much the same
so I truly understand your frustration. Unfortunately the only
solution is investing a lot of time in performance optimizations for
KMail/Akonadi. Most likely it's many different issues that show up
only under some circumstances so it might not be easily
visible/obvious where the problem is. And it's been like this for many
many years.

Best regards,
Dāvis

trešd., 2021. g. 29. sept., plkst. 00:39 — lietotājs Martin
Steigerwald (<[email protected]>) rakstīja:
>
> Martin Steigerwald - 12.09.21, 17:52:14 CEST:
> > I use PostgreSQL.
> >
> > Still it often enough is unbearable.
> >
> > One IMAP account that I limited from 30 to 7 days server-side by using
> > "find -delete", cause Akonadi would just insist to synchronize inbox
> > needlessly a lot of times, blocking deleting mails and moving mails
> > in KMail for even for local maildir access for minutes and longer.
>
> In addition to that displaying a folder with about 40000 mails is still
> very slow before KMail shows anything.
>
> Thus I moved some 13000 mails to a different folder and waited more than
> 7 minutes for that operation to complete:
>
> [Akonadi] [Bug 443095] New: Moving mails to a different folder is very
> slow
>
> https://bugs.kde.org/443095
>
> I really hope one day I am able to use KMail without micro managing
> things for having a performance that is at least barely bearable.
>
> This is on a ThinkPad T14 AMD Gen 1 with AMD Ryzen 7 PRO 4750U 8 core
> processor with hyperthreading, 32 GiB of RAM and 2TB Samsung 980 Pro
> SSD. Taking more than 7 minutes to move 13000 mails on that machine
> without even utilizing at least one full core to the maximum and without
> even using the SSD to its full capability is kind of ridiculous.
>
> Especially when KMail is basically not usable for anything else during
> that operation.
>
> I know every developer works on what they like. And I am grateful for
> any improvement they implement. It is not on me to tell what they should
> do. Yet I still think that it would be best to stop all feature work on
> KDEPIM and Akonadi and fix the outstanding performance and reliability
> issues first.
>
> It is not that any of these issues are new. They are there since the
> switch of KDEPIM to be Akonadi based.
>
> Best,
> --
> Martin
>
>