GNOME Bugzilla – Bug 735161
HTML email processing resource expensive
Last modified: 2015-03-05 11:02:34 UTC
When sending an e-mail (usually with probably 10+ recipients in to/cc) as is typical in business applications (read:Outlook), once you start getting quite a few e-mails in a row and mixed html and images and the message sizes start getting bigger, the reply window loads fine. However I've noticed when I type my message and push send, one of two things sometimes happen: 1) CPU usage on one of my cores goes to 100% and evolution goes gray for a few seconds until it finishes processing then it sends the message. 2) Evolution completely locks up and doesn't use CPU but evolution locks up and I can't use it and have to kill it manually (signal 9). This is using evolution-ews. I haven't tested with IMAP however I will test with that. I'm running Ubuntu 14.04 x64 on a Thinkpad T530 with an Intel i5 with a SSD built in, so I got a plenty fast system. Let me know if you need additional data. This is my first bug report so I don't know what all is required so I'll be happy to get more data.
Which exact evolution and evolution-ews versions are you using?
3.13.4. It's the one in the Ubuntu PPA repos.
I think it's CPU overhead on the new webkit composer. If you highlight a lot of mixed text/html content/images even, it locks up the CPU until it finishes processing. It's pretty easily reproducible from Ubuntu 14.04: 1) Set up PPA 2) Set up an Exchange account (I think Office 365 would work too, anything that uses EWS) 3) Create an e-mail with quite a few bits of content and several pages (should be able to push Page Down on the keyboard like 20 times). Ensure you're using HTML. 4) Observe in top the evolution process consume 100% CPU.
http://gnome-evolution-general.1774414.n4.nabble.com/Evolution-3-13-3-td4659415.html I'm not the only one.
I am not really sure what an "email chain" is...
It's when you have several people cc'd on an e-mail (usually for business purposes). The problem can also occur if you just compose an e-mail with a bunch of content. It happens when you do the following: 1) Have several people cc'd 2) Have several e-mails go back and forth with a reply all. 3) Have your reply format set to inline. 4) It's all HTML. 5) If you throw in some images/fancy html tables/content. 6) Push send. 7) Open top from a terminal and see it consuming CPU cycles. If you have a Gnome based WM (default of Ubuntu for example), Evolution even darkens. It takes a while to process and then the little "sending" animation with the gnome foot moving it's "toes" finally goes on the composing window.
Hi Paul, can please share (if it is possible) one of these messages somewhere (i.e. attach the message here)? It will be helpful. Thank you
Created attachment 289666 [details] LibreOffice Example
Please attach a message itself instead of putting it into some container like a LibreOffice document. Also note that Bugzilla is public (email addresses etc).
I have this problem, too.
Created attachment 289684 [details] Example https://drive.google.com/file/d/0BykRKSvavV8YR3dmM1dINEVmMUE/view?usp=sharing This is the link in case the 7z file won't work.
Created attachment 290727 [details] strace I ran a strace during the send process.
Added strace. I ran it during a message locking up while sending causing 100% CPU (started right away) then killed it as it unlocked and started working again.
I see in the strace that there is some ongoing spell checking, which might not be done on send, there is no need for it. It's true that the message is preprocessed in some way, before being sent. The 3.13.90 should work better in some extent, especially with inline images.
I just tried tried the current git master of evolution with your test message (comment #11) and I see like a second and half to three seconds (subjective measure) delay with high CPU usage and evolution frozen when sending the message. Evolution is just processing the content:
+ Trace 234783
Thread 1 (Thread 0x7f8a952a2a40 (LWP 27148))
Let's deal with this within bug #732457. *** This bug has been marked as a duplicate of bug 732457 ***