On Monday, 13 November 2006 at 15:27, Rocco Rutte wrote: > Hi, > > * Vincent Lefevre [06-11-13 15:30:28 +0100] wrote: > >On 2006-11-13 12:06:55 +0000, Rocco Rutte wrote: > > >>The attached patch prints some progress for both cases. The second part > >>for the "plain" search looks a little strange when messing with the > >>'msg' variable and mutt_clear_error() in case we have a match. But I > >>didn't really find another way to not loose the 'wrapped to top|bottom' > >>messages which are composed even before matching a single message. > > >This could be a nice patch, but it makes the limit function very slow, > >at least when applying it on headers, e.g. ~ffoo: instead of being > >immediate, the limit now takes about 6 seconds on my 52500-message > >mailbox. > > I know, but the pattern is quite trivial. The problem are more those > cases where do you limit on ~bfoo for a 52k maildir folder (where mutt > needs to perform lots of I/O for looking at 52k files with regex). > > * Vincent Lefevre [06-11-13 15:37:42 +0100] wrote: > >On 2006-11-13 12:06:55 +0000, Rocco Rutte wrote: > > >>Another thing I'm not sure about: should we add something like > >>$search_inc analogous to $read_inc and $write_inc? On fast systems with > >>totally trivial searches it can be quite expensive to update the search > >>progress for each single message... > > >Hmm... I now understand what you mean by that (my terminal doesn't > >display everything, so I was wondering...). IMHO, the update of the > >search progress should be time-based, e.g. every second should be > >sufficient. > > I don't think time-based is a good alternative to $search_inc. The > reason is quite simple: when you have 52k messages then mutt needs to > query the time 52k times. And if the search is trivial so that > search/limit is done in <1 second, it will slow things down drastically. > And then mutt will display progress even if there's no need to since > getting the time takes so long. And working around this with alarm() or > friends is no option, IMHO. > > Anyway, thanks for quick feedback! > > Attached is take #2 which adds $search_inc along with an entry in > UPDATING. The default is 0 which means no progress. Compared to the > first patch one more message is gone... so that with the default value > the behaviour is exactly as it was before (...which is mutt policy if I > recall correctly). > > As some first tests showed, a value of 10 looks okay so that could be > another option if the patch gets accepted... I think it'd probably be good to try to unify the progress code somehow, so that things using read_inc/write_inc/search_inc/net_inc go through the same code path. And I think the way to save screen updates might be to cache the last value (I think there's a field for that in the progress bar struct) and skip printing if the value is unchanged. Also, I think it's fine if read_inc controls search progress as well. Searching can be seen as a form of reading.
Attachment:
pgpcu8uHyB7qt.pgp
Description: PGP signature