Re: mutt - slow mbox'es
Hi,
> Why do you need md5 on the entire message? Doesn't a header-only md5
> suffice?
because the length of the body is also stored in the header. So if you
modify the body this length wouldn't be updated and mutt keeps crashing.
> I guess the problem you're seeing is that mbox is already quite efficient,
> so almost anything you'd do to cache information from it in yet another
> file would only add up to incremental performance gains.
<thnx to Nicholas to save me some work and doing the benchmark>
> With maildir, you start out far worse with nothing, so you have far
> more to gain by caching headers. (Try a 300MB maildir with no
> headercache, and I think you'd sooner die than wait for it to load ...
> hehe. . .)
I already did that, and decided to write a header cache before I die.
The size doesn't count in that case, but the number of messages.
The performance aspect isn't that clear to people who have a fast PC with
fast disk IO. My PC at home opens a uncached maildir and mbox message
both in ~ 3 seconds. However where I have to read my eMails at the
moment at a SunFire280R it's a big improvement to have the maildir
header cache. I am talking about 25 seconds vs. 4 seconds in worst case
scenarios for opening 30.000 messages within in a 90 MByte
mailbox/maildir.
> If you're serious about scalable performance, I'd suggest a real database
> server (like mysql) for the mail store. Trying to emulate a database
> with the filesystem isn't really The Right Way (TM).
The day I start using mysql to store my eMail is the day I shoot me.
> You just got me curious about an interesting possible user-mode
> filesystem, actually: How about a filesystem server providing a virtual
> maildir from an mbx back-end? Network clients can use the virtual maildir
> over NFS about as safely as a real maildir. Local clients can use the
> mbx back-end directly, or the virtual maildir, if it's more convenient
> (say, for the mairix symlink trick).
hmmm. Just add nfs-safe locking to mbx?
Thomas