Re: Slowness

[Moon@MIT-AI]

I've been working on finding out why switching buffers is so slow in Zwei.
The most useful page-trace is in the file AI:MOON;.FOO 4.  Here are some of
the reasons I've found so far.  (There are more).

The *ZMACS-BUFFER-HISTORY* list gets looked at by DELQ.  This list has one
cons for each buffer in the editor, and these conses are generally all on
different pages.  The list should be added to with APPEND rather than CONS
so that it gets copied.

The modes stuff seems to touch quite a few pages, partly because it uses
the Lisp interpreter.

Exposing and de-exposing the mini-buffer window swaps in a bit-save array,
probably the one for the lisp listener.  This then kicks out all kinds of
useful stuff.

Due to the real-time delay of switching buffers, once it comes back into
TYI, all the other processes in the machine wake up and touch various
pages (those that don't wake up tend to touch a page or two needed by
their blocking conditions, e.g. pc-ppr-output-hold-flag).  This probably
wouldn't happen if it wasn't for the big bit-save array.

I'd like to try changing Zwei so that the mini-buffer is always exposed, but
just "turned on and off".  Alternatively we could have a small blank window,
preferably with no bit save array, which is under the mini-buffer.

Another idea would be to implement RMS's idea of having a blank window which
appears at some point in the ACTIVE-WINDOWS list.  Anything below this can't
have little bits of itself displayed.  Also of course this window would know
not to save its bits, even when doing partial-screen hackery, since it is
always blank.  Then ZED would expose the blank window then the editor window.
This would prevent the lossages at the bottom of the screen and between the
two window in 2-window mode.