GNOME Bugzilla – Bug 548826
Evolution 2.23.90 is very slow fetching the messages from the server
Last modified: 2013-09-13 00:57:34 UTC
Evolution 2.23.90 seems to be painfully slow when downloading new messages and fetching them from my IMAP server. 2.22.x was definitely faster, and IIRC 2.23.6, though slower than 2.22.x seemed to me faster than 2.23.90.
There are major changes in design with camel db summary implementation.
Cosimo, do you have any filters, if so what filters you have. Definitely we dont do much while downloading, but surely there are changes during filtering.
No, mail filtering is done on the server side and I have no filters inside Evolution.
Cosimo, Any details one whatz going on the console? Can you start with export CAMEL_DEBUG=all and capture the console logs and paste me during mail check ? It shouldn't be slow at all really.
I have a similar problem when fetching mail from POP. After fetching the mails themselves, the "send & receive" dialogue says there's a "Storing folders" operation going on that takes up to 10 (!) minutes which constant disk trashing. (Sometimes [rarely] it's faster, but never less than 30s.) (And the next operation, "Expunging", then fails because apparently the connection has timed out (?)). I don't have many filters; the ones I do have are just moving mail to different folders and mark some mail as read. They weren't a timeconsuming step in evo <= 2.22 either. The folders the mails are being sorted into aren't very big either, I have 2 with ~80k mails, then one 20k and a 10k one, and a couple even smaller ones. In ~/.xsession-errors, messages like this appear: ("Bugmail" is a folder name of a ~80k mail folder) [...] removing cache for Bugmail 87406 0x861e368 done .. now 87406 [...] Saving 1/57 dirty records of Bugmail removing cache for Bugmail 57 0x861e368 done .. now 57 [...]
chpe, Just get me a glance of the gdb trace, when you think it is consuming too much time. It is possible, there is a loop somewhere. Too much changes, due to disk summary branch merge. Thanks in adavance.
Can you try wit 2.23.92 and get me more logs? Thanks
I am seeing severe slowness when fetching mails. The slow operation seems to take place before actually fetching the messages. =========== DB SQL operation [SELECT uid,flags FROM 'linux-kernel-list' order by bdata collate mbox_frompos_sort] started DB Operation ended. Time Taken : 25.786432 ########### This is from gmail via POP. Messages are then sorted by filters and moved to folders based on mailing-lists. The linux-kernel-list folder currently contains only 14K messages so 25s seems a bit excessive. I will attached the full debug output.
Created attachment 126184 [details] debug output with CAMEL_DEBUG=all
I'm seeing this too. After fetching ~200 mails from the server, the disk thrashes for 5-10 minutes before my vFolders update themselves. This is a clear regression from 2.22.
(In reply to comment #9) > Created an attachment (id=126184) [edit] > debug output with CAMEL_DEBUG=all Peter, which is the version you are using?
> Peter, which is the version you are using? The debug output was with 2.25.4. The situation seems to be much improved with the just released 2.25.5.
(In reply to comment #8) > DB SQL operation [SELECT uid,flags FROM 'linux-kernel-list' order by bdata > collate mbox_frompos_sort] started > DB Operation ended. Time Taken : 25.786432 There is an obvious mistake in frompos_sort function. - return (a1 < a1) ? -1 : (a1 > a2) ? 1 : 0; + return (a1 < a2) ? -1 : (a1 > a2) ? 1 : 0; And moreover, returning the differential between a1 and a2 will be fine.
Created attachment 127139 [details] [review] Fix mistake Move frompos_sort function to a new file named camel-local-private.c, and rename the function to camel_local_frompos_sort. Use camel_local_frompos_sort in both camel_spool_summary_new and camel_mbox_summary_new. And the copy right of camel-local-private.c is Srini who is the original author of frompos_sort function.
Hiroyuki, you rock!!!. To trunk and stable
Committed to both. 2009-01-28 Hiroyuki Ikezoe <poincare@ikezoe.net> * camel-local-provider.[ch]: Move frompos_sort from camel-mbox-summary.c, and rename to camel_local_frompos_sort. And just return substraction a2 from a1. * camel-mbox-summary.c, camel-spool-summary.c: Use camel_local_frompos_sort for camel_db_set_collate. Srini, what do you think about this bug? My patch makes performance up, but it must be negligible. So I think this bug should be still kept open.
The disk trashing would be fixed with 565780. Its with a sqlite-vfs we over come the ext/fsync issue.