From xemacs-m  Mon Dec 16 11:32:06 1996
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with ESMTP id LAA24508; Mon, 16 Dec 1996 11:32:05 -0600 (CST)
Message-Id: <199612161732.LAA24508@xemacs.cs.uiuc.edu>
To: turner@lanl.gov
cc: xemacs-beta@xemacs.org
Subject: Re: 19.15-b4 bench results (Hanoi) 
In-reply-to: Your message of "Sun, 15 Dec 1996 23:57:33 MST."
             <199612160657.XAA02385@branagh.lanl.gov> 
Date: Mon, 16 Dec 1996 11:32:03 -0600
From: Chuck Thompson <cthomp@xemacs.org>

    John> When I use a frame of the size I normally use (the full
    John> height of my screen, I believe 58 lines or so), it's slow.
    John> Times like I showed before, over 10.  When I use a tiny
    John> little frame, just big enough to display the towers, it
    John> rocks.  Under 4 seconds.

It would be useful if you could do this for as many heights between 4
and 58 as possible.  I'm interested in knwoing whether the running
time slowly builds up or whether there is a huge jump in there
somewhere.


    John> It also matters if there are other frames up (I made the
    John> mistake of trying it again after I'd started composing this,
    John> with a VM frame up as well as a frame containing this msg,
    John> and even though I stopped writing, it was slow).

I think I may actually have figured out what is going on here.  I
probably already knew it and had just forgotten.  I can't prove it
without doing more than the 5 minute code read it took to come up with
the hypothesis, though.  Fixing it will be tricky as well.  It
involves the handling of the buffer and extents changed flags.  They
need to be smarter than they currently are but there is already
special code to make sure they do as little as possible because they
are called an unbelievable number of times (Quantify is your friend).
It would not be hard at all to make the cure worse than the disease.



			-Chuck

