GNOME Bugzilla – Bug 625069
Slow message fetching
Last modified: 2011-03-07 13:57:03 UTC
Let's profile why is message fetching so slow. I mean message itself, the one where exchange_mapi_connection_fetch_item is used. The initial study shows that attachment fetching (with streams) is quite slow, and that attachments are (tried) queried even when there is no indication on the message itself that it contains any attachments. I'll dig into this more, as it's quite bad to see a simple plain text message with body "eee" fetching for almost 4 seconds. If interested: 0 s 304 ms 723 us (open folder took) 0 s 299 ms 417 us (openmessage took) 0 s 0 ms 016 us (build props took) get_attachments 0 s 291 ms 487 us (GetAttachmentTable) get_attachments 0 s 279 ms 990 us (SetColumns) get_attachments 0 s 255 ms 920 us (QueryPosition) get_attachments 0 s 256 ms 844 us (Query rows) 1 s 334 ms 286 us (get attachments took) 0 s 0 ms 012 us (get recipients took) 0 s 490 ms 139 us (read body streams took) 0 s 529 ms 069 us (getprops took) 0 s 0 ms 009 us (read generic streams) 0 s 508 ms 026 us (release took) 0 s 0 ms 026 us (decode took) 3 s 466 ms 110 us (before release) 3 s 466 ms 119 us (after release - total)
Created attachment 166442 [details] [review] ema patch for evolution-mapi; Couple things, like refetching streams multiple times makes it horribly slow. I also changed the body stream fetching function, it was unnecessary complicated.
Created commit d520e93 in ema master (0.31.6+)
see bug 586199 comment#1 and comment#2
*** Bug 643720 has been marked as a duplicate of this bug. ***
Hi, Just wanted to know, if this bug,, marked as fixed, has been released with which version of evolution-mapi? I have been using evolution-mapi v 0.32.1 and the fetching/downloading of messages is still painfully slow.
See comment #2, it's included since 0.31.6. The thing is that the fetching can still be slow, but with a compare of 0.31.5 and before it's significantly quicker, due to not refetching values which are already downloaded. There are still some more options to improve it a bit, like using libmapi's fast transfer, but it will wait till evolution-mapi will depend on the latest openchange, which may happen for 3.2, if everything will go smooth.