[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time to merge scratch/correct-warning-pos into master, perhaps?
From: |
Alan Mackenzie |
Subject: |
Re: Time to merge scratch/correct-warning-pos into master, perhaps? |
Date: |
Tue, 25 Jan 2022 11:27:27 +0000 |
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).
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, (continued)
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/22
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/22
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/23
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/23
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/23
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/24
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/24
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/24
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/24
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?,
Alan Mackenzie <=
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/26
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/01/26
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/26
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/25
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Óscar Fuentes, 2022/01/25