So after an APPEND, Binc has to scan the mailbox for changes, which takes longer time with larger mailboxes. But that's only half the story, because a scan is usually so fast that you won't notice it. The problem is that the mailbox cache file needs to be written to also. The reason for this is that once the appending client has seen the message, it must assign a UID to it. In order to keep the UID delegation in sync with other concurrent clients, the UID must be stored in the cache file. So every time you APPEND a message to a mailbox your client has selected (which is almost always the case), a big file is created, synced and renamed.
Well, in my case, the cache file is only 1.1MB, which I would expect to take only about 22ms to write, if it were actually going to disk rather than cache. This leaves about 2.480 seconds unaccounted for. I'm guessing this must be the scan you describe. Have you put any effort into speeding that up for 1.3? If not, maybe I'll take a look at it...
The good news is that in 1.3, we'll add the MULTIAPPEND extension (rfc3502.txt). This allows clients to copy several messages in one go, and Binc will then delegate several UIDs in one go, and the cache file will only be written to once for the entire copy operation.
Do many clients actually support MULTIAPPEND? If not, it doesn't help much...
Seth
