[PATCH] Re: IMAP: improve quickchanged() performance

[Sebastian Spaeth]

On Mon, 11 Apr 2011 19:19:44 +0200, Nicolas Sebrecht <nicolas.s-dev at laposte.net> wrote:
> On Mon, Apr 11, 2011 at 06:33:11PM +0200, Sebastian Spaeth wrote:
> > 
> > For each folder we were making a second IMAP request asking for the
> > latest UID and compared that with the highest UID in our
> > statusfolder. This catched the case that 1 mail has been deleted by
> > someone else and another one has arrived since we checked, so that the
> > total number of mails appears to not have changed.
> > 
> > I wonder if we want to capture this case in the quickchanged() case and
> > am throwing this patch in for discussion by removing the check. It
> > improves my performance from 8 to about 7.5 seconds per check (with lots
> > of variation) and we would benefit even more in the IMAP<->IMAP case as
> > we do one additional IMAP lookup per folder on each side then.
> > 
> > The downside is that we don't catch mails in the above scenario (someone
> > deleted a mail remotely and a new one arrived)
> 
> Can't we try to fetch a deleted UID, then? How do we handle such case?

If a message only got flagged as Trashed, it will still be there and be
included in the count. Only if the deleted message has been expunged, it
will be be gone. And then the message count would be reduced by
one. (Does that answer your question?)
 
> What's going on the next sync? Do we detect both changes and propagate
> them locally?

Yes, we detect it properly on the next full sync, just not in the quick
case.

I am not sure what and if the above change is good or not, that's why
I've thrown the patch up for discussion :-).

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110411/a91720bb/attachment-0001.sig>