Dynamic windows FLAME

[David Vinayak Wallace <Gumby@MCC.COM>]

Executive summary: They're too damned slow.

Dynamic redisplay is really really slow!  I used to think that it was
only1 my0 DW programs which were slow, and that there was something I
didn't understand about DW.  But I've looked around at the system
software which uses DW and I realise that it's slow too!

The window debugger is a good example.  I tried to resolve the domain
host sdflhfhasd.dflkhadsfhsda, and broke the process while it was in
process-wait.  Then I typed c-m-W.  Working with the top frame wasn't so
bad; going down the stack was hell.

Try this: Run the same program I did and enter the window debugger the
same way.  Set your frame to be (flavor:method
neti:domain-query-internal neti:domain-with-cache).  Then wait a LONG
time for the code window to display.  Scroll around the code window.
Might as well get a cup of coffee!  This molasseslike redisplay affects
the entire program.  Just typing () to the prompt causes a 6-second
delay while it updates the unchanged displays.  I find it hard to
beleive that this delay could be due to computing which elements have
changed, as the inspector and the old window debugger didn't have this
problem.

Unfortunately as more and more system programs become DW-ified the whole
system will slow down, and much of the advantage of using the Symbolics
environment will be lost.  Good benchmark figures are good, and may help
sell a few machines, but who'll believe the numbers if the machine 1feels
0slow?


By the way, since there has been much discussion of memory thresholds in
recent days on this list, I should mention that I have sufficient memory
such that the display debugger doesn't page when doing redisplay.  This
is on a 3630.