[Akonadi] [Bug 338571] Performance Regression: Folder synchronisation in Akonadi 16.08 (actually in any release, starting with KDE 4.14) very slow, compared to kMail from KDE 4.13.x

[Tore Anderson]

https://bugs.kde.org/show_bug.cgi?id=338571

Tore Anderson <tore at fud.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WAITINGFORINFO              |---
             Status|NEEDSINFO                   |CONFIRMED

--- Comment #52 from Tore Anderson <tore at fud.no> ---
OK, I have now tested KMail 5.14.1/Akonadi 20.04 in a freshly installed VM
running Fedora 33 Rawhide. Then I compared it to the behaviour of Thunderbird.

tl;dr:

* KMail/Akonadi spends ~63 minutes on opening a large IMAP folder (133k
messages) that Thunderbird spends ~8 minutes on. 688% increase with
KMail/Akonadi.
* KMail/Akonadi generates an overall higher load average than Thunderbird does
(even without taking into account that it does so for a much longer period of
time)
* KMail/Akonadi ends up requiring 1703 MiB of disk space, Thunderbird only 124
MiB. 1273% increase with KMail/Akonadi.

So by every single observable metric, KMail/Akonadi is *extremely* inefficient
and slow.

In fact it manages to use more disk space than Thunderbird does in the end,
even *before* any IMAP account has been created (cf. comment #49). That is just
ridiculous.

Here is the exact test procedure I used. I'm using the IETF public IMAP server,
so anyone can try to do the same.

1. Launched KMail, dismissed the initial account setup wizard.
2. Settings -> KMail settings -> Receiving tab -> Add...custom account -> IMAP
3. General tab:
   * Account name: IETF
   * IMAP Server: imap.ietf.org
   * Username: anonymous
   * Password: anonymous at ietf.org
   * Uncheck download all messages for offline use
   * Uncheck regular checking of e-mail
   Advanced tab:
   * Encryption: none
4. Pressed OK, waited for folder list to be downloaded
5. Found the folder named just "ietf" in the list, clicked on it as I started a
stopwatch (@11:40). This folder has about 133.000 messages in it.
6. Waited until folder sync and threading had completed
   After ~15 minutes: folder sync 22% completed, 15-min load average 0.52
   After ~30 minutes: folder sync 47% completed, 15-min load average 0.88
   After ~45 minutes: folder sync 73% completed, 15-min load average 1.39
   After ~60 minutes: folder sync 100% completed, 15-min load average 1.63
   At this point, KMail is still busy doing stuff. Status bar says «grouped X
of Y threads», «processing X of Y messages», etc.
   After ~63 minutes: KMail finally idles. 15-min load average 1.61
7. Closed KMail
8. du -ms ~/.local/share/akonadi -> 1703 MiB

I then compared with Thunderbird's behaviour:

9. Launched Thunderbird (version 68.8.0)
10. In inital account wizard:
    * E-mail address: anonymous at ietf.org
    * Password: anonymous
    Click "Manual settings":
    * Incoming server name: imap.ietf.org
    * Incoming SSL: none
    * Incoming authentication: regular password
    * Configured a random outgoing SMTP account (since it's required)
    * Clicked "Test Again"
    * Clicked "Advanced settings"
    * Server settings page: Unchecked "Look for new messages on startup"
    * Server settings page: Unchecked "Look for new messages every 10 minutes"
    * Synchronisation and storage page: Unchecked "Keep messages in all folder
for this account on this computer"
   Press OK
11. In advanced config editor: set mail.server.default.using_subscription to
false
12. Restart Thunderbird (apparently necessary for
mail.server.default.using_subscription to take effect), let it load the list of
shared folders
13. Clicked the "ietf" folder and started stopwatch
    Waiting until folder sync was done:
    After ~5m: 98k of 133k messages processed (~74%), 5-min load average  0.68
    After ~8m: completed. 5-min load average 0.62
14: du -ms ~/.thunderbird -> 124 MiB

Tore

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.