Re: Mark messages in mailbox as read without massive performance hit?!
* "Matthew D. Fuller" <fullermd@xxxxxxxxxxxxxxx> [2005-12-29 08:52 -0600]:
[...]
> Now, I don't dispute that theoretically there's a point where the
> lines cross and mbox wins. But I think that point is a lot farther
> out than you're suggesting it is, and that some of the realities of
> how mutt does things push it even farther. And empirically, I've
> always found mbox to be orders of magnitude slower on status changes
> (particularly in the degenerate case where you're changing one or a
> few messages in the middle of the mailbox), on any size active mailbox
> I ever use (up to maybe 10 thousand messages, though usually below 5).
ACK.
> Having written mbox parsing code, I deeply hate the [blend of totally
> different] format[s], but it has a lot of advantages in compactness
> etc. I never let it near an active mailbox, but I use it for archives
> all the time, because it's more compact, leaves my preciouss inodes
> alone, and is much, MUCH faster to read. But they fall over pretty
> hard in most use-cases that aren't read-almost-entirely, IME, both in
> performance, and in making me sweat about the myriad ways it can
> corrupt my data and lose the history of all my favorite flamewars.
You're not so only one doing it this way. Mbox has the additional
advantage that it can be easily compressed with the compressed folders
patch.
> > Obviously, the user who posted this message is running into this
> > problem, or else we would not be having this discussion...
>
> Now, in THIS case, I certainly don't buy it. The OP is suggesting
> he's seeing problems on mailboxes on the order of *50* messages. That
> shouldn't break down on FAT12, much less any filesystem on a *nix
> system installed in the last 15 years. I doubt I could measure by
> hand the time 50 rename()'s take on a 386SX. Something else is
> tripping him up.
ACK. His macro, which is so slow, does not contain a sync, so I'm
not sure if writing the changes back to the disk is the real problem.
I could imagine something with a cmplicated $simple_search, since
~U seems to be faster.
Nicolas
--
http://www.rachinsky.de/nicolas