Version: unspecified (using KDE 4.6.4) OS: Linux I have installed the most up to date kdepim packages with the appropriate akonadi packages from Kubuntu experimental. I use a pop3 mail and the akonadi resource goes to 90-100% and so makes system unusable. Reproducible: Always Steps to Reproduce: having a pop3 mail box defined Actual Results: mail is very slow to download and cpu goes to 100% Expected Results: just started
Same here, I'm using KDE/KMail2 4.7RC2 (4.6.95), Akonadi 1.5.80. Each mail download takes very long time using 100% of CPU and prevents me synchronizing mail several times per day.
Akonadi 1.6.0, same issue. Isn't the slowness caused by checking for duplicit mails (which would be unnecessary if it worked - bug 271231)? I have a lot of mails here (1806MB).
I can confirm the behaviour. KDE 4.7 on gentoo. I checked with nethogs and akonadi is mostly idle on the network while it keeps the cpu busy. The akonadi console shows long pauses between activity. At the current rate the sync could take days. On a side note kmail doesn't show any meaningful progress indication as every folder sync is 100% complete in a few seconds in its opinion then sits there at 100% for the rest of the time needed.
Is there anything I can help with? Enable some logging, look into code (change something) or so? This problem annoys me a lot (the synchronization is unusable), so I would like to help analysing it. I don't know where to start looking.
Created attachment 62906 [details] Patch to fix slowness of pop3 mail reading The code uses QMap::key(value, default_value) to search for the right message UID. According to Qt documentation, the method is: This function can be slow (linear time), because QMap's internal data structure is optimized for fast lookup by key, not by value. For lot of emails, the function is really really slow, because it tries to match every value until it finds one. I will send the patch to reviewboard as soon as I get an account created.
Created attachment 62910 [details] Patch to fix slowness of pop3 mail reading (git version)
Oldřich, thank you very much for working on this! Looking forward to the reviewboard patch. Seems to be ok at first glance. Good job finding the slowness. When I coded the resource, I didn't code for efficiency and tested only with my usual amount of mails (I don't keep mails on the server), therefore I never noticed the problem. Did you run the unit test of the POP3 resource? It is actually a complete system test that brings up a test akonadi server and everything, it tests a lot of stuff of the POP3 resource. I hope it still works :)
(In reply to comment #7) > Oldřich, thank you very much for working on this! Looking forward to the > reviewboard patch. Seems to be ok at first glance. Good job finding the > slowness. When I coded the resource, I didn't code for efficiency and tested > only with my usual amount of mails (I don't keep mails on the server), > therefore I never noticed the problem. > > Did you run the unit test of the POP3 resource? It is actually a complete > system test that brings up a test akonadi server and everything, it tests a lot > of stuff of the POP3 resource. I hope it still works :) Um, actually no. I did the change, let the modified Gentoo ebuild do the compilation/installation work and that's it :-) It is review #102353 under kdepim group.
Git commit a5be56cf25949db75c88c2c70f720d8c7d2b5ace by Thomas McGuire, on behalf of Oldřich Jedlička. Committed on 21/08/2011 at 19:51. Pushed by tmcguire into branch 'master'. Fix bad performance when fetching mail with many mails on the server. With many mails on the server, the usage of QMap::key() was slowing down things a lot. BUG: 277597 REVIEW: 102353 M +15 -1 resources/pop3/jobs.cpp M +2 -0 resources/pop3/jobs.h M +4 -0 resources/pop3/pop3resource.h M +6 -3 resources/pop3/pop3resource.cpp http://commits.kde.org/kdepim-runtime/a5be56cf25949db75c88c2c70f720d8c7d2b5ace
This bug fix isn't part of 4.7.1
> This bug fix isn't part of 4.7.1 Sorry, right, no one merged it to the 4.7 branch yet. I did that now with a9f648f4d2c7b0086c256981a9f08f71335b5798, so it will be in 4.7.2.