[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
window-systems.
With jit-lock, I've tried to optimize redisplay performance with lazy
font-locking.
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
practice.
20.7
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
21.0.93
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
bench.el
Description: bench.el
- Re: comments on ntemacs 21.0.91, Eli Zaretskii, 2000/12/01
- Re: comments on ntemacs 21.0.91, Andrew Innes, 2000/12/01
- Re: timing Emacs 21 (was: comments on ntemacs 21.0.91), Robert J. Chassell, 2000/12/01
- Re: timing Emacs 21 (was: comments on ntemacs 21.0.91), Eli Zaretskii, 2000/12/01
- Re: timing Emacs 21 (was: comments on ntemacs 21.0.91), Gerd Moellmann, 2000/12/02
- Re: timing Emacs 21 (was: comments on ntemacs 21.0.91), Eli Zaretskii, 2000/12/02
- Re: timing Emacs 21 (was: comments on ntemacs 21.0.91), Robert J. Chassell, 2000/12/02
- Re: timing Emacs 21 (was: comments on ntemacs 21.0.91), Robert J. Chassell, 2000/12/04
Re: comments on ntemacs 21.0.91, Eli Zaretskii, 2000/12/01
Re: comments on ntemacs 21.0.91,
Gerd Moellmann <=