[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on ntemacs 21.0.91

From: Gerd Moellmann
Subject: Re: comments on ntemacs 21.0.91
Date: 02 Dec 2000 14:25:27 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.93

"Eli Zaretskii" <address@hidden> writes:

> > Date: Fri, 1 Dec 2000 03:17:56 -0500
> > From: Miles Bader <address@hidden>
> > 
> > [I have to wonder what machine the previous poster is running on; I find
> > emacs 21 redisplay more than fast enough on a pentium 133, and quite blazing
> > on anything faster...]
> Gerd, I seem to recall that you once said Emacs 21 was slightly faster
> than Emacs 20, as far as redisplay is concerned.  Is that right? 

It depends, as usual.

Lower-level parts of redisplay (I include faces as part of redisplay)
have inevitably become slower because it has a lot more to do.  For
example, it's necessary to determine, for each character glyph, its
exact dimensions and if it overlaps adjacent glyphs.  In the old
redisplay nothing had to be done, everything was of the same fixed
height and width which were computed once, and there were no
overlapping glyphs.  This inherent additional cost must be paid
in many situations, just think of the handling of variable-height
lines when scrolling; it's everywhere.

Another very important factor is the difference in the amount of
information that has to be recorded in glyph matrices for each glyph.
Just filling out the larger matrices takes a lot of time.

(When I started to write the second new redisplay, I discussed with
Richard some optimizations that could be done for the case that all
text is fixed width and height, but our conclusion at that time was
that it was probably not worth doing because (a) there wasn't a real
problem, (b) it would make redisplay a lot more complex than it
already is, and (c) computers get faster anyway.)

Q: How can the new redisplay be sometimes faster than the old one?

A. I've done various optimizations on a higher level.  To mention
a few:

I've tried to optimize the display optimizations which try to avoid
scanning text and producing glyphs in the first place.  (You'll
probably notice that 21 is generally faster than 20 when there is more
than one window on a frame, and you'll find that Hanoi is faster (use
the old version which doesn't do delays).)

I've tried to optimize the update phase which determines from current
and desired glyph matrices which glyphs to output to the screen on 

With jit-lock, I've tried to optimize redisplay performance with lazy

X optimizations, etc. etc.  In the result, comparing old and new
redisplay is like comparing apples and oranges.

During the development of redisplay, I've used a simple benchmark
program, mainly for finding out when I had screwed up again some
display optimization.  Below are some numbers from that bechmark test.

Measuring redisplay performance is hard to do in a meaningful way.  I
don't claim that these benchmarks measure something meaningful in


Function Name                      Call Count  Elapsed Time  Average Time
=================================  ==========  ============  ============
bench-mark-hanoi                   10          16.705412     1.6705412
bench-mark-kill-line               10          7.6920209999  0.7692021
bench-mark-move-within-window      10          0.9147900000  0.091479
bench-mark-next-line-down          10          48.618565999  4.8618565999
bench-mark-next-line-down-2        10          7.156828      0.7156828
bench-mark-next-line-up            10          50.792287     5.0792287
bench-mark-next-line-up-2          10          9.068764      0.9068764
bench-mark-random-points           10          19.023042     1.9023042000
bench-mark-scroll-pages-down       10          14.653712     1.4653712
bench-mark-scroll-pages-up         10          13.719638000  1.3719638
bench-mark-single-char-insertions  10          2.377699      0.2377698999
bench-mark-single-line             10          12.336718     1.2336718
bench-mark-split-window            10          10.752775999  1.0752775999
bench-mark-update-window           10          0.4405        0.04405


Function Name                      Call Count  Elapsed Time  Average Time
=================================  ==========  ============  ============
bench-mark-hanoi                   10          9.782297      0.9782297
bench-mark-kill-line               10          13.130005     1.3130005
bench-mark-move-within-window      10          1.636391      0.1636390999
bench-mark-next-line-down          10          51.497098     5.1497098
bench-mark-next-line-down-2        10          18.868783     1.8868783
bench-mark-next-line-up            10          41.411730999  4.1411731
bench-mark-next-line-up-2          10          8.47344       0.847344
bench-mark-random-points           10          19.697533999  1.9697533999
bench-mark-scroll-pages-down       10          14.174609     1.4174609
bench-mark-scroll-pages-up         10          15.929746000  1.5929746000
bench-mark-single-char-insertions  10          3.252302      0.3252301999
bench-mark-single-line             10          15.882458     1.5882458
bench-mark-split-window            10          37.523734     3.7523733999
bench-mark-update-window           10          0.405698      0.0405698

Attachment: bench.el
Description: bench.el

reply via email to

[Prev in Thread] Current Thread [Next in Thread]