<<< Date Index >>>     <<< Thread Index >>>

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/