From xemacs-m  Mon Dec  9 15:29:01 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 PAA20758; Mon, 9 Dec 1996 15:29:00 -0600 (CST)
Message-Id: <199612092129.PAA20758@xemacs.cs.uiuc.edu>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@xemacs.org
Subject: Re: Benchmarking XEmacs versions (was Re: Additions to Shane Holder's bench.el) 
In-reply-to: Your message of "09 Dec 1996 12:47:47 PST."
             <m2iv6bcumk.fsf@altair.xemacs.org> 
Date: Mon, 09 Dec 1996 15:28:58 -0600
From: Chuck Thompson <cthomp@xemacs.org>

    sb> Shane, it does not look like you disabled all the error
    sb> checking that is normally disabled in delivered XEmacsen.
    sb> Chuck and Martin could you please comment on the Large File
    sb> scrolling benchmark versus the Tower of Hanoi?

Scrolling is possibly the single most difficult thing to do
efficiently once you allow variable height lines in a dynamic buffer.
Web browsers have it easy.  No one is going to whack a paragraph out
of the middle of things.

Scrolling is also one of the big differences between the current
redisplay engine and the Epoch redisplay engine.  Epoch, believe it or
not, didn't actually do anything at all to the scrolling code to take
into account variable height lines.  I corrected this partially in the
port I did of the Epoch redisplay engine to Lucid Emacs but the design
of the Epoch redisplay engine made it impossible to completely fix
it.  This is one of the many reasons I rewrote the entire display
engine.

With variable height lines pretty much every single optimizing
assumption made to speed up scrolling goes right out the door.
Scrolling from top to bottom isn't that bad but going back up is
another story.  You can't have any idea how many lines above the
current start point will actually fit on the screen.  Unless you
happened to have already displayed it once before.  And that is just
what I did.  There is a line start cache which keeps track of where
the line beginnings are.

This is something that should really be a more generic mechanism.
That would allow for a number of ways to speed up scrolling as well as
allow for scrollbars that actually work on the number of lines rather
than the number of characters.  At the moment the scrolling cache is
actually implemented as just a sliding window.  Every time redisplay
updates the display it updates the cache.  As long as the newly
displayed region overlaps or is right next to either end of the cache,
the data is just tacked on.  Otherwise the entire cache is invalidated
and started over from scratch with the newly displayed region.
Somewhere it is stated that in 19.14 redisplay uses about 1/3 less
memory than it did previously.  That was because of an optimization
(i.e. elimination of something I was doing really stupidly) to the
caching mechanism.

I've never quantifiably measured all of this before but you don't have
to to see the effect.  It is very noticable to the human eye.  Try the
following two tests with the Large File scrolling test.

	1)  Load the file and scroll to the end of the buffer making
	    sure you don't do so so fast that even a single line is
	    skipped.  Unless you have a really fast machine this
	    probably means tapping PgDn instead of holding it down.
	    Now, hold down the PgUp key.

	2)  Kill the buffer and load the file again.  Use M-> to skip
	    to the end of the file.  Hold down the PgUp key.


You should see that scrolling backwards is remarkably faster in the
first case than it is in the second.  The cache provides really
remarkable improvements in scrolling speed _if_ the necessary
information is already in it.

If all of this sounds like a thesis, there's a reason.  The author of
the Epoch redisplay, Chris Love, wrote his Master's thesis about it.
At the end of it he listed a number of unanswered questions about a
number of design decisions.  The thesis I've been writing for over two
years :-) is to be about why one in particular was a really bad choice
(though you couldn't have know that at the time).  Scrolling is by far
the best example for showing why it was a bad decision.



			-Chuck

