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

[Nicolas Sebrecht]

On Mon, Apr 11, 2011 at 10:57:11PM +0200, Sebastian Spaeth wrote:
> 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?)

Not sure. Are we talking about _remote_ changes while syncing?

> > 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.

Ok.

-- 
Nicolas Sebrecht