Subject: Re: NTEmacs 20.2 vs NT4 System Tray + running two versions.

From: Andrew Innes <[email-masked]>
Date: Thu, 19 Feb 1998 13:20:54 GMT

On Wed, 18 Feb 1998 19:04:07 -0500, "Dmitry Yaitskov" <[email-masked]> said:
>>Do both emacsen therefore use the lisp, info and other directories for
>>20.2.1?
>
>No, they seem to be intelligent enough to correctly determine their base dir
>(i.e. the one they were started from), so that all other directories are
>also correct.

runemacs deliberately sets emacs_dir based on its own location - I added
that feature for my own convenience, since I have separate test and
normal use builds on my machine.

>>Haven't really noticed the speed decrease as yet,  not enough time to
>>spare :-(
>
>I have ctrl-up mapped to scroll up, and ctrl-down to scroll down. In 19.36,
>I had to disable the menubar to get acceptable scroll speed (i.e. enough for
>window refresh to keep up with my key repeat rate). In 20.2, even though I
>have no menubar, pressing and holding ctrl-up or down results in ugly
>refreshes of only about upper 1/3 of the window. The rest is not refreshed,
>which makes scrolling practically useless for me. :(( (and btw, disabling
>the scrollbar did not have any effect at all).

Last autumn, I did some profiling of the redisplay engine to try and
identify the major bottlenecks (which isn't terribly relevant any more,
as Emacs will soon have a brand new redisplay engine).  However, I also
compared the performance of 20.2 with 19.34.6, out of curiosity.

I found that 20.2 was actually measurably quicker than 19.34.x in some
tests, and a bit slower in others.  Overall, there wasn't much
difference.  My primary testing procedure was to time how long it takes
to execute (next-line 1) 3000 times (while displaying the etc/NEWS
file), calling (sit-for 0) after each move to force a full redisplay.

(I noticed a few minor bug fixes in 20.2 that would affect whether
certain optimizations are used, which were not being used in 19.34.  I
suspect that is mainly responsible for any differences I observed.  Note
that my tests didn't exercise the MULE code, since the NEWS file is in
plain ascii.)

The main outcome of my testing was actually to determine that
calculating the line and column position on the modeline (or just one of
them) slows down redisplay significantly - almost 100% for both of them
(ie. redisplay time is nearly doubled by enabling line-number-mode and
column-number-mode).  I also noticed that side-by-side windows showing
the same buffer were much slower than one window on top of the other,
which was the main problem I hoped to address.

Anyway, since a new redisplay engine has already been written, most of
this discussion is now moot.  The new engine has been designed from
scratch to work well on pixel-oriented displays, and should avoid at
least some of the inefficiencies of the old engine because of that.  It
also supports proportionally spaced fonts, and mixing fonts of different
heights and widths, so is a major improvement in that regard too.

AndrewI