Version: (using KDE 4.2.2) Installed from: FreeBSD Ports kmail seems to be unresponsive and slow while using up all cpu time on one core. This can happen for both: displaying the contents of a mail folder and displaying a message. Both can take between 2 and 20 seconds. Today I had this happen displaying the contents of a folder having 150 plain text emails. Then selecting an email to get it displayed took another 10 seconds. The system was idle otherwise only burning cpu for kmail.
What type of mail account are you using? IMAP, DIMAP, POP3 ( local folders ). Does it happens allways or only when kmail is retrieving new mails?
this happens on a DIMAP Account. not only when kmail is retrieving so I guess of your choices it would be "always". So far I have not been able to pin-point it to specific actions happening.
Created attachment 33711 [details] Example Mail I experienced this behavior with some messages, too. I'm using a local cyrus imap server. I copied such a message to a local folder in kmail and tried to open it. It takes about 5-10 seconds. If th message is on an imap server it takes about 20 seconds. So, I guess the problem appears in local folders as well as in IMAP folders. However, tf IMAP is involved, the problem becomes more visible. I attached the example message to this bug.
I'm also having this problem. My system is KDE 4.2.3 with QT 4.5.1. In my case, when I try to open an e-mail, the time that KMail takes to open it is proportional to the numbers of files attached with this message. I'm using a gmail account with dIMAP. The problem has the same characteristics described previously, when I try to open a e-mail as described in the last paragraph, KMail hangs-up, starts to use a big amount of CPU and took 5 to 20 seconds to get the message open. Except for this slowly, everything on KMail regarding these messages with a big numbers of attached files seems to be working fine. So I'm able to open every attached file and see the message without any problem.
I am not sure if this is related. Moving messages to a different folder also takes long, even to show just the menu
If you search for "KMAIL IMAP slow" on google, you will get a considerable number of results of people reporting the same issue here described. So I think that the bug status should be changed from UNCONFIRMED to CONFIRMED. I haven't mentioned my KMAIL version: 1.11.3.
I'm still having this bug on KMAIL 1.11.4 (KDE 4.2.4).
Same problem here, can you please change to CONFIRMED ? System Debian Testing, KDE 4.2.2.
With kmail 1.11.90 from svn trunk r976506 the attached message in comment 3 is viewed in less than 1 second with a P4 in a VBox (from a Dimap server in the host machine). Perhaps this bug is related to bug 186551.
Perhaps. I have also some messages which are displayed slow, and kmail almost freezes and is for 20 seconds unresponsive. Could i help you resolve this problem somehow ?
You can help if you could attach the slowest mail in the bug report. (or if you are a programmer, trying to fix it :-) ).
Created attachment 34545 [details] Slowest mail I am not programmer :-) So i created an attachment.
I guess this will be fixed in kde 4.3.0. For me, you slowest mail opens in less than 1 second (using the latest development version). (Pentium 4, 3.20 Ghz, 256Mb the Virtual Machine).
Hmm interresting, so thank you for reply. But i'm on the Debian Testing so i need to wait some time till 4.3 will be avaliable in repository. But i'll test it and give you feedback.
Well, the message attached by Martin in Comment #13 takes almost 5s to open here (AMD Turion X2 2,1Ghz, 3GB RAM). I'm using the stable KDE 4.2.4, but I'll install KDE 4.3.0 beta 2 to see if this problem continues. I have noticed that the time to open the e-mail is somewhat proportional to the number of attached files. I have an e-mail of about 10MiB with just one file (.pps) that takes less than 1s to open. But another e-mail with 2MiB but with more than 50 pictures takes more than 10s to open.
*** Bug 195549 has been marked as a duplicate of this bug. ***
I think it is time to change the status from UNCONFIRMED to CONFIRMED, isn't it?
*** This bug has been confirmed by popular vote. ***
Hi So i made some further investigation of this problem and i found some strange thing. I made strace of kmail and click on this problematic mail. And in the strace output there was during 2 minutes only this /usr/share/icons/oxygen/48x48/emotes/image-jpeg.svgz", R_OK) = -1 ENOENT (No such file or directory) Of course with different directories and extensions, but filename is always image-jpeg. Then i try to create emopty file image-jpeg.svg in all dirs, and now it take max 3 seconds to display this mail, and no more kmail freezes. Then i deleted these files and it again took cca 1 minute to display the message and kmail freezes for a while. So i changed the icon theme to Crystal and everything works well again. But the problem is with Oxygen icon thene. Maybe it's related to bug 191666, but it's strange that so few people have this problem. Could it be only distribution problem ?
I can confirm the behavior observed in comment #20.
My linux distribution is Gentoo, what is yours?
Ubuntu (jaunty)
Hi, my is Debian testing (squeeze).
It is not acceptable if a broken or missing icon theme can take down an application like this. There might be a distribution problem but this is only triggering the underlying error.
I found the reason and will try to fix it. The problem is that KMail renders a icon for each attachment in the header list. This icon is based on the mime type of the attachment. So when you have an attachment with mimetype image/jpeg, it will look for the icons named "image-jpeg". Those don't exist, and it will eventually fallback to a generic image icon.
Ok, but there must be a big problem, because as i can see from strace, kmail try to find this icon repeately for 4 minutes, without falling back to default (generic) icon.
SVN commit 984088 by tmcguire: Speed up display of mails with many attachments, by introducing a cache in the code that maps the mimetype to an icon name. The icon name was often not found, like for image_jpeg, and that was slow. According to the bug report, this improves message display from 20 to 3 seconds in some cases. Thanks to Martin for finding the reason for the speed problem. BUG: 189961 BUG: 191666 M +1 -0 CMakeLists.txt A iconnamecache.cpp [License: LGPL (v2/3+eV)] A iconnamecache.h [License: LGPL (v2/3+eV)] M +2 -6 kmmsgpart.cpp M +1 -1 kmreaderwin.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=984088
SVN commit 986223 by tmcguire: Crossport r984088 by tmcguire from trunk to the enterprise4 branch: Speed up display of mails with many attachments, by introducing a cache in the code that maps the mimetype to an icon name. The icon name was often not found, like for image_jpeg, and that was slow. According to the bug report, this improves message display from 20 to 3 seconds in some cases. Thanks to Martin for finding the reason for the speed problem. CCBUG: 189961 CCBUG: 191666 M +1 -0 CMakeLists.txt A iconnamecache.cpp trunk/KDE/kdepim/kmail/iconnamecache.cpp#984088 [License: LGPL (v2/3+eV)] A iconnamecache.h trunk/KDE/kdepim/kmail/iconnamecache.h#984088 [License: LGPL (v2/3+eV)] M +2 -6 kmmsgpart.cpp M +1 -1 kmreaderwin.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=986223
Thank you very much for your efforts but, even 3s for displaying a plain text mail is very long on current computers. I understand that kmail will never be as quick as cat but maybe this should be looked into some further.
*** Bug 198739 has been marked as a duplicate of this bug. ***
Still this is not completely resolved. While the time for parsing a message with many attachment went down from over a minute to about 1-3 seconds (btw great job discovering the root cause of this) I still consider this slow. Having a mail with some huge attachments also takes some time to parse (usually 5-10s). I think the message parser still needs some improvement. Kmail is just not as snappy as in 3.5 kde versions.