Re: Exmh 2.7 Flist much slower?

>>>[email protected] said:
 > On Thu, 30 Dec 2004 11:02:43 PST, John Beck said:
 > 
 > > Brent> I found some simple optimizations in mh.tcl MhReadSequences that
 > > Brent> improved my flist time from 18 seconds to under 1 second.
 > 
 > > 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.
 > 
 > Weirdness indeed. I have 160 or so folders, 32 have unread mail in them.  Ab
     out
 > 217K messages total, about 15K unread.  flist's were taking 20-30 seconds
 > sometimes for me.  I did a cvs update, and flists were down to 7 seconds.  T
     he
 > odd thing is that the *old* code (Oct 19 datestamp on mh.tcl) is now down to
      7
 > seconds as well.  

I should be clear about my timings.  I'm looking at the Log window and
the debug output.  The background task periodically does an Flist internally
to look for newly arriving messages.  That is the step that was taking
several seconds and is now under a second.  When you use the GUI "Flist"
button it does more work than that, including updating the UI.  Another
change in 2.7 is that there are more frequent "update" calls to refresh
the display, which is why you seen the contents of the folder cache
changing as each folder is checked.  I haven't spent any time trying
to optimize that.  You may need a setup that has lots of folders with
unseen messages in order to get a visual effect that appears faster.

 > > There does appear to be such a something, which would be the ftoc (i.e. sc
     an)
 > > 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 lik
     e
 > > 	20 + (n / 2)
 > > meaning that e.g. with n set to 14, there would actually be 27 lines in th
     e
 > > display, though the baseline of 20 may have been a little smaller, and the
     re
 > > 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 versi
     on)
 > > I got back the behavior I'm used to.
 > 
 > I noticed that as well - I never *did* figure out if I did that when I added
      the
 > code to support separate panes for the message display and flist, or if it w
     as
 > broken before that.  It's tied into the whole resize-the-pane code - it look
     s
 > like the ftextLines value doesn't *really* do much, because the flist pane g
     ets
 > built after and then there's all the 'pack' calls. 

The pack calls are all one-time setup of the window hierarchy.
The resize-the-pane code is all about computing a new ftextLines
value.  Then that value is set, and a trace on the variable triggers
a call to ExwinFixupFtextLines that configures the height of the
window.  This is all strangely indirect, and at some point I should
convert to the panewindow widget in Tk 8.4.

One thing to check is what the computed ftextLines value is compared
to what is displayed.  When you use the black diamond to resize the
panes it is recomputing that value, then setting the display based
on that.  There is some crufty code to convert from the pixel locations
of the resize line to the number of text lines that match that.  It
is possible that that code was somehow damaged.

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]