Re: Time to merge scratch/correct-warning-pos into master, perhaps?

[Alan Mackenzie]

Hello, Gregory.

On Tue, Jan 25, 2022 at 08:59:00 +0000, Gregory Heytings wrote:

> >> At least the test suite is not a micro-benchmark.  I exercises a large 
> >> subset of Emacs features, and I don't see anything in these ~110K lines 
> >> of Elisp that make them significantly different from other Elisp 
> >> programs.  My conclusion is that Emacs is now, on average, about 10% 
> >> slower.

> > Your conclusion is premature.  While micro-benchmarks don't represent a 
> > typical Emacs usage, neither are the tests in the test suite.  They are 
> > run in batch mode, and the don't involve important Emacs subsystems, 
> > such as the display engine.

> > So the actual slowdown in "normal" usage could be quite different from 
> > what the test suite measures.


> I think you understood what I meant: bytecode execution in Emacs is now, 
> on average, about 10% slower.

The C level EQ operation takes twice as long when the operands do not
match, and the same time as before when they do match.  When one of the
operands is a literal nil, there is no increase in execution time.

The above doesn't apply to compilation, whether byte or native, where
the slowdown in the EQ operation is more marked.

> Are there other benchmarks (not micro-benchmarks) that could be used
> to reach what you would consider a mature conclusion?

There is Andrea Corallo's elisp-benchmark package.

You could try the following, in conjunction with benchmark-run.  It
scrolls through an entire buffer:

(defun time-scroll-b (&optional arg)
  (condition-case nil
      (while t
        (if arg (scroll-down) (scroll-up))
        (sit-for 0))
    (error nil)))

-- 
Alan Mackenzie (Nuremberg, Germany).