On Mon, 2008-08-18 at 01:42 -0400, Asheesh Laroia wrote:
But if it really is because of THREAD, you're in luck. I've almost finished thread index implementation and I'm also considering making it available for v1.1 as a plugin.
That would rule. (Unless I can already get it as part of the 1.2 hg tree, in which case I'm not averse to upgrading)
v1.2 hg tree does have thread indexing code, but it's a bit buggy and I've already rewritten most of it. I did several tests yesterday and it's beginning to look pretty good, although there are still some bugs. I'll try to get those fixed soon and commit the code. After that it's actually time for v1.2.alpha1 release.
Attaching to the imap process in gdb and interrupting to get a stack trace every once in a while, I find it's mostly (80%) in this:
#2 0xb7e28ff3 in readdir64 () from /lib/tls/i686/cmov/libc.so.6 #3 0x0806fbe1 in maildir_scan_dir (ctx=0x80f6170, new_dir=false) at maildir-sync.c:421
I guess the problem isn't then threading but maildir syncing.. There would be two solutions to avoid this:
Switch to dbox format. :)
Add a new mail_assume_only_dovecots=yes setting that makes Dovecot not rescan the maildir unless it clearly sees that the timestamp has changed under it. That also means that if there was an external non-Dovecot modification to cur/ at the same second as Dovecot was doing its own changes the external modification wouldn't be seen (until something forced a rescan).
I guess 2) would be nice, but I don't know when I'll have time to implement it.
Can maybe Dovecot show me the last cached version of the folder so I can see the index immediately, and in the background re-sync that? That way opening folders could be instantaneous, and each next IMAP action could give me a chance to see the synchronized state once it's ready.
I guess that would be the 3) possibility. :) But way too much trouble.