On Thu, Jul 22, 2004 at 02:24:55AM EDT, Thomas Glanzmann wrote: > > Well, if you feel like hacking up Mutt support for the mbx format, > > you can have the only mailbox format that performs even better than > > the mbox format. Your other option is to use the IMAP header cache > > with a connection to your local UW-IMAPd (which already supports mbx) > > running on mbx mail stores (which is my setup, minus the header cache - > > I don't need header caching, since I rarely leave my 300 megabyte inbox). > > why noone did that already? probably because the current craze is maildir ;-) > Are there some numbers available? It's a full-binary-indexed file. That gives it better theoretical read performance (in userland, mind you) than the reiserfs gives your kernel using its balanced tree algorithm. I don't have any benchmarks handy, but something that can outperform the fastest open source filesystem on Earth without the overhead of constant system calls (if you have enough RAM to store most/all of the index) sounds like a winner to me. (On my own server, it's interesting to note that the difference between mbox and mbx backends isn't all that great, since my bottleneck is CPU power, not disk bandwidth. Even so, my expunge seems at least 2-3 times faster, and general read performance is at least twice as fast.) > How many > lines have other dbx implementations? I assume you're looking for mbx implementations? Here's some stats from the c-client library (the one used by UW-IMAPd), comparing the mbox code to the mbx code: $ wc unix.c 2425 12513 84923 unix.c $ wc mbx.c 1721 8165 59027 mbx.c > How many man hours would it take > to implement it? Based on the above statistic, I'd be optimistic on the man-hour prediction :-) - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpIFg4GveghO.pgp
Description: PGP signature