GNOME Bugzilla – Bug 682277
Multiselect of messages causes slow UI update
Last modified: 2013-08-20 09:26:14 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=849221 User claims that selecting more than 2000 messages makes behave evolution strangely, very slow update of UI when adding more messages into selection. I'm able to reproduce this even with IMAP folders, though the user had this behaviour with EWS folder. Below is backtrace of this state, which the user gathered. Steps to reproduce: a) select many (2000+) messages in message list by keyboard (like Shift+PgUp/PgDown/ArrowUp/ArrowDown) b) see how the response of UI gets slower and slower when adding more messages into selection The window title updates count of selected messages, only message list doesn't update its content until some timeout.
+ Trace 230708
Thread 1 (Thread 0xb77a78c0 (LWP 2955))
It's pretty easy to fix e_mail_shell_view_update_sidebar(), it calls message_list_get_selected() only for counts, but I found other issue, and that's update_actions. It's called on any change, but many unnecessary things are happening, just to be accurate. It also includes constant recreation of Labels submenu of popup menu. I would suggest these changes for update_actions: a) do not call it on each change in message list, not for all actions, but only for actions on toolbar b) add a parameter to update-actions, something like "for-popup" or "force-all", which will be used to force update of all actions. c) cache result of message_list_get_selected() in MessageList and reuse it for consecutive calls of that function (or message_list_selected_count()) and update it only on selection change d) on those "present accurate menu", like which items to enable/show based on message flags of the selection, or labels, set an upper limit for whose items to calculate it. I suggest 100 selected messages. If there are more messages selected then show/enable all items, same as provide Label popup menu items with an "unknown" state (neither checked, nor unchecked) Matthew, does it make sense? (I do not like c) much, but that's used on too many places, all around sources, thus what one can do.)
+ Trace 230710
Thread 1 (Thread 0x7f51599bba00 (LWP 2312))
+ Trace 230711
+ Trace 230712
Thread 1 (Thread 0x7fd00153fa00 (LWP 31455))
Above a three more places I was able to get backtraces for.
First thing I would try is defer calling update_actions() to an idle callback, if there is not one already scheduled. That way numerous change notifications during a single main loop iteration result in a single update_actions() call, instead of one call for each change notification. Could even build this directly into EShellView with an e_shell_view_update_actions_in_idle() function. Once that's done we can evaluate whether further optimizations are needed.
Created attachment 221979 [details] [review] initial evo patch for evolution; I suppose you meant something like this. My tests showed that this doesn't help that much, evolution still uses one core when I hold Shift+PageUp to select many messages (I ended in 6000+). To be honest, the selection seems quicker here, but I know we still can do better. One side note, about Labels submenu, if there are selected messages which some have set label and others not, then the menu shows the label name as disabled, thus user cannot set it to all selected messages. I'm pretty sure it's not what we want. If you agree, then I can file a new bug report for it.
(In reply to comment #7) > One side note, about Labels submenu, if there are selected messages which some > have set label and others not, then the menu shows the label name as disabled, > thus user cannot set it to all selected messages. I'm pretty sure it's not what > we want. If you agree, then I can file a new bug report for it. I did that because I didn't want to show inconsistent checkmarks next to the labels. But I suppose the checkmarks could represent a union of all labels in the selected messages. For example if you select 4 messages with only a Red label, and 4 messages with only a Blue label, then the menu would show checkmarks next to the Red and Blue labels.
A lot of the action states really only care if 0, 1, or N > 1 messages are selected. They don't need the full UID list or even an exact count. If the MessageList could quickly report its selection state in terms like NONE, SINGLE or MULTIPLE that might help here.
Comment on attachment 221979 [details] [review] initial evo patch $:andre\> git apply --check 682277.patch error: patch failed: modules/mail/e-mail-shell-view-private.c:955 error: modules/mail/e-mail-shell-view-private.c: patch does not apply error: patch failed: shell/e-shell-view.c:81 error: shell/e-shell-view.c: patch does not apply error: patch failed: shell/e-shell-view.h:220 error: shell/e-shell-view.h: patch does not apply
Created attachment 252360 [details] [review] evo patch ][ for evolution; Updated patch. It lets me select (with Shift) 7500 messages page-by-page with responsive UI. The CPU is still high, but evolution's UI is not frozen.
Created commit b7e728d in evo master (3.9.91+)