GNOME Bugzilla – Bug 743926
Slow to render large plain text emails
Last modified: 2015-04-21 08:41:40 UTC
Created attachment 296010 [details] backtrace warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [New LWP 30015] [New LWP 20819] [New LWP 20578] [New LWP 20395] [New LWP 20394] [New LWP 20393] [New LWP 20392] [New LWP 20386] [New LWP 20385] [New LWP 20384] [New LWP 20291] [New LWP 20283] [New LWP 20246] [New LWP 20245] [New LWP 20244] [New LWP 20243] [New LWP 20242] [New LWP 20241] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". WebCore::Style::attachRenderTree (current=..., resolvedStyle=...) at ./Source/WebCore/dom/ShadowRoot.h:125 125 ./Source/WebCore/dom/ShadowRoot.h: No existe el fichero o el directorio.
+ Trace 234615
Thread 1 (Thread 0x7f806f50d940 (LWP 20238))
I think I have found the mail that causes this... but I cannot find its file under .local/share/evolution dirs :S
Created attachment 296013 [details] mail.bz2 I think it's one of this really big mails
Thanks for a bug report. I see it too, but that's due to the message size. If I let webkit work long enough (about 10-30 seconds) then it renders fine finally. I do not think it's doable for Evolution to fix this in any way, but it would be nic to know an option from Tomas, whom knows webkit better (the thing I think of is what if evolution has set some callbacks on webkit which are triggered often during such long messages render phase). Tomas?
But, in my case, it takes several minutes (well, next time I will leave it running to see if finally it gets shown ;)
The response time may depend on the machine speed, thus it's possible it takes longer on slower machines. I just re-tried and it took 1 minute and 22 seconds to show the message (my previous subjective measure with "10-30 seconds" was obviously wrong).
I stepped around a similar mail and dive a bit into the investigation about the slowness. It took me to two places: a) CamelMimeFilterToHTML is causing one part of the slowness, when converting plain text emails into HTML code b) evolution has a workaround for webkit's bug: https://bugs.webkit.org/show_bug.cgi?id=89553 it's done in a way of zooming in and out (or out and in) the view, which causes render of the message two more times. That means that the message is rendered 3 times, before it's finally shown to a user. While there cannot be done much with the b), maybe except of moving to webkit2 or fix the issue in webkit or find another workaround to make frame-flattening work, then there is probably a room to improve the a). I guess so at least.
*** Bug 733543 has been marked as a duplicate of this bug. ***
*** Bug 733877 has been marked as a duplicate of this bug. ***
The feel of how rapidly this goes from inconsequential to impossibly slow gives me the impression that there is some algorithm hiding underneath that is O(n^2) or O(n^3) that should be O(n)... Making Text/CSV/etc. attachments not always display inline by default might help address some of these problems until they underlying bug is fixed. For example, per this suggestion: https://mail.gnome.org/archives/evolution-list/2015-February/msg00061.html
*** Bug 720928 has been marked as a duplicate of this bug. ***
I spent half of the day on this and I was able to reproduce the slowness in a pure WebKitWebView too, from which I'd say the problem lies on both ends. The tests showed that webkit2 (currently not used by the Evolution) 2.8.1 behaves significantly better than 2.6.5 (see [1] for more information). While I'm not able to influence WebKit code, I can at least change the workaround evolution has, which I mentioned in the comment #6. I made a change to do one of the zooming with a minimal content in the view, thus it's lightning fast, while the second zoom call is done with the filled content. As it's only one zoom call, not two, the time spent on the zooming is half after the change. I'm closing this bug with this change in evolution. The rest should be done by the port to use webkit2 and in the webkit code itself. A side note, the CamelMimeFilterToHTML is working with whole lines. It means when the body of the message is one long line, then it searches in the same line multiple times (the content is read in 4KB chunks). Thus there is a little room for improvements as well, but as the usual messages are also line-based, then I'll keep it that way for now. Created commit 772bc9c in evo master (3.17.1+) Created commit 8e54b0e in evo gnome-3-16 (3.16.2+) [1] https://bugs.webkit.org/show_bug.cgi?id=143868
Bug 733877 (https://bugzilla.gnome.org/show_bug.cgi?id=733877 - freezing on CSV attachments) was closed as a duplicate of this bug, but when there is an attached CSV, Evolution should not attempt to parse the CSV at all when just selecting the message. I'm assuming that as of comment #11 an attached CSV will still be parsed in this case? If so, should that bug be re-opened or this one?
(In reply to Stephen from comment #12) > when there is an attached CSV, Evolution should not attempt to parse > the CSV at all when just selecting the message. Thanks for the reminder, I overlooked it. There is a plan to avoid attachments "pre-parsing" together with the port of Evolution to use WebKit2. Tomas, do we have a bug report for it already, or you'd prefer to reopen Stephen's bug report?
(In reply to Milan Crha from comment #13) > Tomas, do we have a bug report for it already, or you'd prefer to reopen > Stephen's bug report? Tomas told me there is no bug opened for it yet, thus I'm reopening Stephen's.