Hi, * Kyle Wheeler wrote:
> What about using the mtime/ctime timestamp on the cur directory to > determine whether it's changed since the last time it was read? All > flag changes, message deliveries, etc. *should* update the > directory's inode atime/ctime. That way you don't need a > configuration knob, and it should be a generalized optimization that > applies to all situations. It'd add a stat call to the opening > process, and you'd have to store the last-known-mtime in the cache, > but... We do support storing arbitrary values in the cache, so that'd work. Some time ago I've also toyed with dumping the cache. As a partial result I know that the 3 major backends support key traversal. So that'd work, too. The problem is when you have only one hcache for all folders because then we're CPU-bound as we need to check each key if it belongs to the mailbox we currently open. But for one-db-per-folder we can even drop that check I guess and just can iterate over the keys. So the only real issue is when the FS isn't accurate about the times for the directory. > for enormous cached maildirs it'd provide a big win (for > efficiency, you'd probably want an update-able cache, rather than an > append-only cache, but that's true in general). The cache is updateable for some time now (weeks I think). Rocco
