GNOME Bugzilla – Bug 270324
Evolution Mail is Slow
Last modified: 2005-03-12 17:06:47 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Evolution Mail is mind-bogglingly slow. Incomprehensibly Slow. So slow it takes *minutes* to delete mail or switch between folders slow. So slow I'm wondering if I should bail and use Mozilla Thunderbird. It's a chore to use it. While mail is trying to do, well, anything, my processor is at 100% (according to the Gnome System Monitor Applet). Slowdowns occur from: changing mail folders, deleting mail, changing a mail view (i.e. enable/disable Threaded Message List), displaying HTML-formatted Emails (not as slow as the other operations, but annoyingly slow regardless). Then there's the spam blocker, which slowed down send/receive so much that Evolution was timing out when receiving mail from my POP3 provider. Alas, I've had to disable it just to use Evolution at all. Background: I have Fedora Core 3 installed on a Dell Inspiron 4000 laptop. It's a 700 MHz PIII with 256 MB RAM. Obviously, this isn't the fastest machine around. However, it ran Evolution 1.4 reasonably well, with no major slowdowns to speak of. (There was one issue where receiving mail would crash Evolution, but that's fixed in 2.0.) I have 931 MB of mail archived across 44 folders, so this is a large mail store. I have no idea why Evolution 2.0.2 is slow slow now. I can give you the summary of "top" 51.7 evolution 31.2 at-spi-registry The time taken to load a folder or delete messages from a folder seems (slightly) proportional to the size of the folder -- the smaller the folder, the higher the liklihood I won't have to get coffee while waiting for Evolution. Steps to reproduce the problem: 1. Start Evolution 2. Change to a foder containing lots of messages. (For example, a folder containing 732 messages, all unread) 3. Wait (in this case, ~1 minute) Actual Results: Waiting, annoyance, and turning to a different machine to read mail while waiting for Evolution on the laptop. Expected Results: The folder to change, the message list updated, in a reasonable time frame (reasonable == <= what Evolution 1.4 did). How often does this happen? Always. Additional Information:
perhaps you can try getting some profiling data? it's not at all slow for me and I have far more mail than you... (my inbox alone has close to 2 gig) :\ I have no idea what could be so slow.
Just a guess, some interaction betwen at-spi-registry and evolution. Does Evolution hit at-spi-registry to read mail messages or anything else? What's the easiest way to get the profiling information? I'm working from a FC3 install (though I'll be "yum update"ing soon), and have no easy way of rebuilding evolution from source.
none of the actual mail code hits at-spi at all as far as I know, although I suppose at-spi probably is hit because of ETable and/or GtkHTML? *shrug* without having to recompile evolution, I guess the only way to profile would be to use oprofile or something similar? http://oprofile.sourceforge.net maybe NotZed has some other ideas...
Haven't gotten any further in profiling, but I've run evolution within gdb and gotten a backtrace. From a cursory inspection of the backtrace, it looks like the performance is due to Accessiblity. Thread 1 looks to be in a writev() loop via ORBit, through libatk-bridge and libspi.so. Below is "thread apply bt all" when it's hammering the processor
+ Trace 53372
Thread 1 (Thread -151132480 (LWP 15321))
I'll disable Accessibility and see how things behave.
Disabling Assistive Technology Support/assistive technologies make Evolution run *much* faster. It's actually usable again. I should have tried gdb weeks ago. So apparently this performance bug isn't with Evolution, it's with (a) assistive technologies/ATK/at-spi, or (b) the interaction of Evolution and assistive technologies. From the backtrace it looks like ATK is hit whenever an Evolution tree model node is changed, which explains why the wait seemed to be proportional with folder size. Though this is all just guessing. Should we close this bug, or re-assign it to ATK, or what?
Jonathan: please open a bug against ATK in http://bugzilla.gnome.org Thanks for your effort pinpointing this problem
This is a known a11y issue of e-table/e-tree. We will look at it later.
*** bug 262768 has been marked as a duplicate of this bug. ***
fixed in CVS.
Note for those running KDE and Evolution 2.0: You can turn off Assistive Technologies by running the gnome-at-properties either from a Console or Start Program menu. Deselect the 'Enable assisitive technologies' checkbox, and close. Restart X, and Evolution is faster. Thanks Jon!