Re: Rethinking the design of xwidgets

[Eli Zaretskii <eliz@gnu.org>]

> From: Akira Kyle <ak@akirakyle.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 12:07:38 -0600
> 
> >> It strikes me that perhaps some optimizations may no longer be as
> >> necessary on modern hardware or on GUI displays as they were when
> >> running emacs in a VT on 20 year hardware.
> >
> > Those are very good questions.  I'm not aware of any such
> > investigations since the current redisplay optimizations were
> > implemented around 20 years ago: at that time, Gerd Möllmann, who
> > developed the current display engine, did add optimizations one by
> > one until he got reasonable redisplay performance.
> >
> > Measuring the speedups from each of the several optimizations is
> > an important job, but it's a large job.  For starters, one needs
> > to come up with a large enough and representative enough sample of
> > redisplay use cases, and that is not easy.  So I'd encourage you
> > (or anyone else, actually) to do this important job, but be aware
> > that it could take non-trivial time and effort.
> 
> I see some redisplay tests in tests/manual/redisplay-testsuite.el 
> and scroll-tests.el which seems like it would be a starting point 
> for such a study?

No, not necessarily.  Those just test some tricky situations where
there were bugs at some point.

To find the set of tests to measure the effect of the optimizations,
I'd suggest the following procedure:

  . For each of the optimizations, find a situation where each that
    optimizations gets executed.  ("M-x trace-redisplay" can help
    here.)  Then measure the performance with and without the
    optimization (most of them can be inhibited by setting the
    relevant inhibit-try-* variables; for the couple that cannot, we
    can add more such variables).
    Note that some optimizations are in xdisp.c and some in dispnew.c.

  . Each test case found above should be run with and without
    variable-size fonts, with and without text properties (font-lock),
    and with and without lots of overlays.

  . Additional test cases can be constructed by benchmarking scrolling
    through a large buffer, again with and without the relevant
    optimizations.

I guess there's more, but the above can be a good starting point, and
will produce enough data to analyze the current situation.

> I am a user who frequently wishes redisplay was better which has
> partly motivated my interest in this. Between displaying long org
> mode documents with inline images and long lines of generated latex,
> I'll often see noticeable delay in basic buffer operations such as
> scrolling. This is also exacerbated by the fact that I'm doing all
> of this on a Pinebook Pro which is an arm aarch64 system comparable
> to the raspberry pi. In fact the only way Emacs has been generally
> usable for me on this laptop is with the native-comp branch.

It is possible that a significant portion of the percepted slowness is
due to Lisp that is run either via redisplay hooks or from
post-command-hook and suchlikes.  To see who is the culprit, profile
Emacs during such slow displays, and look at the percentage taken by
redisplay_internal and vertical-motion, as opposed to other functions.