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

[Alan Mackenzie]

Hello, Gregory.

On Tue, Jan 25, 2022 at 21:27:25 +0000, Gregory Heytings wrote:

> > I've just tried timing $ make -j17 check on an up to date master, and a 
> > master two - four weeks old, both configured the same, with native 
> > compilation.  Much of the run time was taken by native compilation.

> > The two times were 42.966s and 48.547s.  That's a difference of just 
> > under 13%.  Not a systematic comparison, since make check may have got 
> > bigger in the last few weeks.

> Which is consistent with the results I reported: about 40% of the time of 
> make check is used for byte-compilation, which is slowed down by ~17.5%, 
> and the rest is execution, which is slowed down by ~11%.

What you reported was more educated guesses than results.  Why don't you
actually _measure_ some hopefully typical Emacs use, and tell us exactly
how you got these measurements.  Start off saying how you configured your
build, followed by calling emacs -Q, with all the other detailed steps
needed to duplicate your measurements.

So far as I am aware, there have been just two comparative measurements
done which don't involve compilation and aren't what you call "micro
benchmarks".  One was my timing scrolling through a C buffer.  That gave
a slowdown of ~1%.  The other was Lars's timing, in his own words:

    "Yes.  I've now done a few more realistic non-micro benchmarks --
    (eww-open-file "/tmp/foo.html") -- and I see no measurable
    performance impact there at all."

..  So the only benchmarks showing a > 1% slowdown are those involving
compilation, and the "micro benchmarks".

[ .... ]

> > There is no "all" in the 10% slow down.  That is a measure of the 
> > slowdown of $ make check, nothing else.

> It's the time to execute ~110K lines of Elisp, exercising various parts of 
> Emacs.  It's IMO a much more significant number than an ad-hoc 
> micro-benchmark.  It's perhaps not the only one to take into account, but 
> it cannot be ignored either.

But as pointed out above, it's not a measured time difference, it's an
estimated one, complete with assumptions which you're probably not
totally aware of.  Would you please present us with some _measurements_.
I think we're all agreed we accept the slowdown in compilation as a cost
of actually doing the job right.  So timings involving compilation aren't
of all that much interest.

> > But nobody else cared enough about the boostrap time to bother putting 
> > in the use of the byte-compiled compiler in early bootstrap until I did 
> > a week or so ago.

> You may have seen that this optimization has no effect without 
> --with-native-compilation.  This may explain that.

The bootstrap time without native compilation is much shorter in any
case.  The point I'm making is that people are working themselves up
into a frenzy about these small slowdowns, yet when they could have
calmly done something about slow bootstrapping didn't really bother much.

-- 
Alan Mackenzie (Nuremberg, Germany).