Re: mutt/2870: color index foo foo ~h pattern causes many fileops
The following reply was made to PR mutt/2870; it has been noted by GNATS.
From: Marc MERLIN <marc_soft@xxxxxxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc: me@xxxxxxxxxxx
Subject: Re: mutt/2870: color index foo foo ~h pattern causes many fileops
Date: Thu, 29 Mar 2007 19:48:44 -0700
On Fri, Mar 30, 2007 at 04:25:04AM +0200, Michael Elkins wrote:
> > 2) Why does adding a message to a folder cause mutt to ignore its entire
> > cache and rebuild a brand new one at resync time, scanning all messages
> > multiple times, when at folder open time, mutt looks smart enough to
> use
> > the cache for already cached messages, and only open/index/scan
> whatever
> > few messages that weren't in the cache already?
>
> Unfortunately, it is possible that a message in the cur/ subdirectory is
> modified in another Mutt which would be undetectable without a full
> rescan. Operations which rewrite the message header such as
> edit-message or {break,join}-threads would cause the cache to be bad.
> You can't rely on the times from stat() because Mutt uses utime() to
> restore the times after an edit.
>
> Mutt assumes the cache is valid when the mailbox is open, so it only
> scans for messaages not already in the cache.
That makes sense, but given the time penalty that this creates, would it be
reasonable to have an option like
set maildir_header_cache_verify = no
(which is what I thought that option did to start with), which would disable
the full resync behaviour? I think most people would be happy to trade not
editing the same folder from two mutts at the same time vs several minutes
of rsync each time anything is modified.
Also, I'm confused, wouldn't modifying a message from a second mutt, update
the cache anyway? (maybe not, but even if not, I'd be happy to have a "do
not do full resyncs option")
> > Fixes would be:
> > 1) mutt should never open a stat the same file 4 times in a row
>
> I am not sure why that would happen, but I agree.
although come to think of it, what really impacted me was actually the fact
that mutt would do this for each and every index color line too, so let's
say 40 stats and open per message if I had index color ~h lines.
If just that bug is fixed, I think it would alleviate most of the slowdown
problems, even if mutt still does full resyncs.
Does that sound reasonable?
Thanks
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/