Re: Exmh 2.7 Flist much slower?

Note: moved to the -workers list as it seemed more appropriate.  Apologies
to Brent if this is undesired, and if so, feel free to move back...

Brent> I found some simple optimizations in mh.tcl MhReadSequences that
Brent> improved my flist time from 18 seconds to under 1 second.  This change
Brent> is checked into CVS.  The problem is that a single Tcl array, mhPriv,
Brent> is used to store a copy of all your sequence state for all folders.
Brent> There were a few places that did foreach element of mhPriv if this is
Brent> what I want, unset the value This is way expensive compared to using
Brent> array unset arrayName indexPattern which can be used to clear a "slice"
Brent> of an array efficiently.  I have 100s of folders with 1000's of unread
Brent> (never to be read?) messages, so it really made a difference for my
Brent> setup.

Yes, it seems faster, though it's not clear how much.  It will be more
obvious (for me) only after I start up with a ton of unread mail, which
usually only happens after logging in after being away for a while.

Brent> I'd appreciate some feedback from folks that use the CVS head for their
Brent> installation.  It seems about time to push out another release anyway,
Brent> and if there is something broken I'd rather find out before that.

There does appear to be such a something, which would be the ftoc (i.e. scan)
cache: I have

*ftextLines:    14

in my defaults file but the new version had it much bigger than that.  By
playing with the number in Preferences, I observed a formula something like
	20 + (n / 2)
meaning that e.g. with n set to 14, there would actually be 27 lines in the
display, though the baseline of 20 may have been a little smaller, and there
were some oddities with n = 0 or 1.  I did not fully understand the diffs to
exwin.tcl, but by backing out its changes (i.e., restoring the 2.7.0 version)
I got back the behavior I'm used to.

-- John