GNOME Bugzilla – Bug 579816
Calendar: extreme slowness adding attendees
Last modified: 2014-03-10 17:50:23 UTC
Using my groupwise calendar / addressbook, I create a meeting, select Attendees, and use the Attendees dialog to add people to it. I search in the "Novell Groupwise Addressbook" - the second contact I add (or perhaps the first) - having cleared the search entry, [ or perhaps just typed a single character ] gives me an application hang for perhaps 5-10 seconds; the trace of the client while it does this is this:
+ Trace 214686
Thread 1 (Thread 0xb5c30780 (LWP 28166))
225 226 path = gtk_tree_path_new (); 227 gtk_tree_path_append_index (path, n); 228 229 if (gtk_tree_model_get_iter (GTK_TREE_MODEL (contact_store), &iter, path)) 230 gtk_tree_model_row_inserted (GTK_TREE_MODEL (contact_store), path, &iter); 231 232 gtk_tree_path_free (path); 233 } 234 (gdb) finish Run till exit from #17 0xb7a0ac84 in row_inserted (contact_store=0x9eb06b0, n=<value optimized out>) at e-contact-store.c:230 [Thread 0xa70f6b90 (LWP 2274) exited] view_sequence_complete (contact_store=0x9eb06b0, status=E_BOOK_VIEW_STATUS_OK, book_view=0x9748100) at e-contact-store.c:624 624 for (i = 0; i < source->contacts_pending->len; i++) { (gdb) p source->contacts_pending $1 = (GPtrArray *) 0xa2e93560 (gdb) p source->contacts_pending->len $2 = 13406 This are quite a lot (13k) of contacts to be adding & sorting I guess - but clearly we are doing something silly - it should be ~instant to sort that many people; looks like some N^2 crept into there (?) Downstream bug id - https://bugzilla.novell.com/show_bug.cgi?id=476133.
Created attachment 133100 [details] [review] Expands the contacts in contact_store rather than using ETreeModelGenerator for better performance This patch reduces the time required to load ENameSelectorDialog from 7 seconds to 3 seconds for loading around 11k contacts.
Patch looks good, just please: - do not add an empty line where not needed (see view_sequence_complete) - consider also removing the model from a tree view (if possible), as any change is probably calling other rutines/signals in a tree view. I noticed the slowness when I was trying to see the state of GtkTreeView as a replacement of ETree/ETable, and detaching it from TreeView before any mass operations and attaching back after done with it, did a good job in performance - fix also this, please > (get_email_count (cached_contact) == get_email_count (contact)) == 1)) - use if (!priv->expand_contacts) { in view_sequence_complete instead of if (!priv->expand_contacts)\n{ As the patch is quite large, commit the modified version to master only, where will be done other tests after that.
Comment on attachment 133100 [details] [review] Expands the contacts in contact_store rather than using ETreeModelGenerator for better performance We are almost a year later, please update the patch.
I have missed this completely. Will take it up post Evolution 3.0.
The issue is better discussed in bug #630504, with another approach (server-side sorting), thus I mark this as a duplicate of it. *** This bug has been marked as a duplicate of bug 630504 ***