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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, Jan 25, 2022 at 14:26:31 -0500, Stefan Monnier wrote:

[ .... ]

> >> I do find the slowdowns discussed here rather worrisome.
> >> I thought the original agreement was that it was OK to install this
> >> change if the slowdown could be brought down to about 1% or below (for
> >> the non-compilation case).
> >> More importantly, I wonder how slowing down EQ by a factor of 2 can end
> >> up costing 10% of runtime when running the test suite.  I think this
> >> deserves investigation.
> > Maybe it's because a lot of the time spent by make check is spent in
> > compilation, whether byte or native.  Compilation _is_ slower, by quite
> > a bit.

> No, we are talking about the execution time:

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.

> Gregory Heytings wrote:
>    In short: byte-compilation is ~17.5% slower, execution is ~11%
>    slower. Nowhere near the "in the region of 1%" that was announced.

I don't think Gregory has ever been specific about what precisely he has
timed, and how.  I have.  And the 1% figure was for a specific timing,
namely scrolling through xdisp.c from start to end, fontifying as we go.

> > When I ran elisp-benchmark on the before and after versions, the change
> > was 2½% (on a native compiled Emacs).

> So, something changes the cost from 2-3% to 11%.  Maybe it's native
> compilation (tho I don't know if Gregory ran these with native
> compilation or not), or maybe it's somewhere in the nature of the code
> in the test suite, or ...

.... or all of these things.  I suspect it's mainly the increased cost of
the compilation.

> Mind you, I consider 2½% to be already quite different from "about
> 1%", ...

Really?  You have a batch job which you were expecting to take a minute.
Now, instead, it takes 61 seconds.  What would you have done with that
extra second, which is now no longer in your life?

> but I think we should first focus on those 11% reports because I don't
> think I'm willing to slow down all execution by 10% just to get better
> position info in the compilation warnings.

We're not talking about "better" position info.  We're talking about
correct versus incorrect; functional versus buggy.  Compilation has got
slower because it's no longer skimping on an essential portion of its
task.

You are taking up the emotional element of Gregory's posts.  There is no
"all" in the 10% slow down.  That is a measure of the slowdown of $ make
check, nothing else.  The time to bootstrap is about 7% - 8% slower
after the bug fix.  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.  Bootstrap has become steadily
slower over the months as features have been added.  Does anybody really
care?  If you scroll through C Mode code fontifying it, the fixed Emacs
is about 1% slower.  If you run the elisp-benchmarks, it's about 2½%
slower.

If we were talking about the output of a chemical factory, a 2½%
reduction in output would probably be serious.  But we're not, we're
talking about a use case where the computer's waiting for the next key
stroke nearly all the time anyway.

But do some comparative timings.  I think you'll find the typical loss
in performance is a good deal less than 11%.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).