[plug] [OT] Gmail Opinions

Cameron Patrick cameron at patrick.wattle.id.au
Thu Jun 17 18:08:20 WST 2004


James Devenish wrote:

| > That's one of my major complaints about mutt.  Even on relatively fast
| > modern IDE discs, it can take the better part of a minute to open a
| > large folder.  I'd love to see it be O(1) for opening a folder;
| > there's no technical reason why it can't be with a little caching.
| 
| What local mailbox format are you using?

Maildir.  Part of the reason that it's so slow is that it has to open,
slurp headers, and close each file in the directory, which is not fun
when there are ~30 000 messages, scattered essentially randomly around
the disc.

I don't want to use mbox.  I've had corrupted mboxes before, the
locking issues terrify me, and no two mailers can quite agree on what
the format is.

| Mutt would need to use a "safe" indexing format in order to avoid
| problem with people or mail daemons making manual changes to
| mailboxes, given that the formats it uses are often "open" ones that
| people (er...me) abuse.

Ahh.  I /think/ the Maildir spec says that Thou Shalt Not Change A
Message Without Changing Its Filename, but I could be wrong.  You
could make the index safe at the cost of stat()ing every file in the
directory.

There are a couple of patches around to implement indexing support,
but they are broken (in terms of the index not matching the message
itself), or offer minimal performance gains (probably because they use
Berkely DB; yuck!).

Part of the problem is that mutt wants to read in all the message
headers when it opens a folder even with the indexing patches.  I'd
think that opening a folder could be made near-instantaneous if it
only has to read the headers of the last N messages, where N is the
height of your xterm.  Heck, if you kept the indices sorted, it
wouldn't even be a problem if you had to hit the original messages to
read the headers.

Cameron.




More information about the plug mailing list