After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 270324 - Evolution Mail is Slow
Evolution Mail is Slow
Status: RESOLVED FIXED
Product: GAL
Classification: Deprecated
Component: ETable
trunk
Other All
: Normal normal
: ---
Assigned To: Li Yuan
Evolution QA team
: 262768 (view as bug list)
Depends on:
Blocks: 271192
 
 
Reported: 2004-12-08 12:51 UTC by Jonathan Pryor
Modified: 2005-03-12 17:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonathan Pryor 2004-12-08 12:51:16 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:
Comment 1 Jeffrey Stedfast 2004-12-08 16:13:05 UTC
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.
Comment 2 Jonathan Pryor 2004-12-08 23:56:22 UTC
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.
Comment 3 Jeffrey Stedfast 2004-12-09 16:57:33 UTC
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...
Comment 4 Jonathan Pryor 2004-12-10 12:48:08 UTC
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


Thread 1 (Thread -151132480 (LWP 15321))

  • #0 _dl_sysinfo_int80
    from /lib/ld-linux.so.2
  • #1 writev
    from /lib/tls/libc.so.6
  • #2 link_connection_read
    from /usr/lib/libORBit-2.so.0
  • #3 link_connection_writev
    from /usr/lib/libORBit-2.so.0
  • #4 giop_send_buffer_write
    from /usr/lib/libORBit-2.so.0
  • #5 ORBit_small_freekids
    from /usr/lib/libORBit-2.so.0
  • #6 ORBit_small_invoke_stub
    from /usr/lib/libORBit-2.so.0
  • #7 ORBit_small_invoke_stub_n
    from /usr/lib/libORBit-2.so.0
  • #8 ORBit_c_stub_invoke
    from /usr/lib/libORBit-2.so.0
  • #9 Accessibility_EventListener_notifyEvent
    from /usr/lib/libspi.so.0
  • #10 gnome_accessibility_module_shutdown
    from /usr/lib/gtk-2.0/modules/libatk-bridge.so
  • #11 gnome_accessibility_module_shutdown
    from /usr/lib/gtk-2.0/modules/libatk-bridge.so
  • #12 g_signal_has_handler_pending
    from /usr/lib/libgobject-2.0.so.0
  • #13 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #14 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #15 gal_a11y_e_table_item_get_type
    from /usr/lib/libgal-a11y-2.2.so.1
  • #16 g_cclosure_marshal_VOID__POINTER
    from /usr/lib/libgobject-2.0.so.0
  • #17 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #18 g_signal_has_handler_pending
    from /usr/lib/libgobject-2.0.so.0
  • #19 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #20 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #21 e_tree_model_node_changed
    from /usr/lib/libgal-2.2.so.1
  • #22 e_tree_memory_node_insert
    from /usr/lib/libgal-2.2.so.1
  • #23 message_list_paste
    from /usr/lib/evolution/2.0/components/libevolution-mail.so
  • #24 message_list_set_folder
    from /usr/lib/evolution/2.0/components/libevolution-mail.so
  • #25 em_folder_view_get_popup_target
    from /usr/lib/evolution/2.0/components/libevolution-mail.so
  • #26 em_folder_browser_show_preview
    from /usr/lib/evolution/2.0/components/libevolution-mail.so
  • #27 em_folder_view_mark_selected
    from /usr/lib/evolution/2.0/components/libevolution-mail.so
  • #28 mail_build_attachment
    from /usr/lib/evolution/2.0/components/libevolution-mail.so
  • #29 mail_msg_free
    from /usr/lib/evolution/2.0/components/libevolution-mail.so
  • #30 g_vasprintf
    from /usr/lib/libglib-2.0.so.0
  • #31 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #32 g_main_context_acquire
    from /usr/lib/libglib-2.0.so.0
  • #33 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #34 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #35 main


I'll disable Accessibility and see how things behave.
Comment 5 Jonathan Pryor 2004-12-10 12:59:16 UTC
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?
Comment 6 Gerardo Marin 2004-12-10 20:30:34 UTC
Jonathan: please open a bug against ATK in http://bugzilla.gnome.org
Thanks for your effort pinpointing this problem
Comment 7 Harry Lu 2004-12-13 10:42:25 UTC
This is a known a11y issue of e-table/e-tree.
We will look at it later.
Comment 8 Harry Lu 2005-01-18 04:52:51 UTC
*** bug 262768 has been marked as a duplicate of this bug. ***
Comment 9 Harry Lu 2005-01-27 07:26:35 UTC
fixed in CVS.
Comment 10 Ryan Erickson 2005-03-12 17:06:47 UTC
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!