On Sun, Sep 29, 2013 at 12:39:03PM -0500, Felipe Contreras wrote:
...
>Which works reasonably fast, but if I read something in Gmail, it
>doesn't get marked as read locally.
>
>If I do 'Sync PullNew PullFlags Push' then the local flags are
>updated, but it takes a long looong time to complete.
>
>Is there a way to update the flags locally fast? What am I missing?
I don't have a problem you've described (as I've mentioned in this
thread already), though I can see mbsync being slow when propagating
flag changes from a local Maildir to a remote Gmail IMAP )-: For
instance, I marked 388 messages as read and it took 3m2s for mbsync to
send it back to Gmail.
I think I know where the problem comes from and how to mitigate it (I've
been postponing writing this suggestion for monthes now, thanks Felipe
for the motivation!). When --verbose mode is enabled one can see mbsync
sending a single STORE command _per each individual messages_, e.g.:
(1 in progress) >>> 7 UID STORE 17913 +FLAGS.SILENT (\Seen)
(2 in progress) >>> 8 UID STORE 17917 +FLAGS.SILENT (\Seen)
(3 in progress) >>> 9 UID STORE 17923 +FLAGS.SILENT (\Seen)
*380+ lines snipped*
(386 in progress) >>> 392 UID STORE 18883 +FLAGS.SILENT (\Seen)
(387 in progress) >>> 393 UID STORE 18888 +FLAGS.SILENT (\Seen)
(388 in progress) >>> 394 UID STORE 18900 +FLAGS.SILENT (\Seen)
And then a remote IMAP server has to handle each such a request
individually, one by one:
6 OK Success
7 OK Success
8 OK Success
*380+ lines snipped*
392 OK Success
393 OK Success
394 OK Success
I propose to benefit from using a sequence-set that is described at
http://tools.ietf.org/html/rfc3501#section-9. This way all 388
independant STORE's may be packed into a single long STORE command,
something like this:
7 UID STORE 17913,17917,17923,...,18883,18888,18900 +FLAGS.SILENT (\Seen)
I haven't had this problem when I used offlineimap. (So far it's the
only thing where offlineimap beats mbsync.) I'm pretty sure it does
exactly this to speed the process up, save network traffic and reduce
load on a server.
I'm using an old mbsync built, something like master@{2012-11-26}. I
apologise in advance if things have changed and all my remarks are
irrelevant anymore.
Thanks (-:
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
