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

[Gregory Heytings]

> > > and what does "execution time" stand for -- is that elapsed time, CPU 
> > > time, something else?
> >
> > The first time printed by "time", that is, the wall clock time.
>
> If you are measuring wallclock time, I don't see how the overall 
> slowdown is a reliable measure of any code performance.  The test suite 
> includes quite a few tests that deliberately wait for some seconds for 
> various reasons, and those times aren't affected by the byte code or the 
> interpreter.

It is reliable, because the slowdown ratio doesn't change between -j1, -j4 
and -j8.

> We need to measure CPU time.

The results are even worse (again 7922131bb2 vs 3b33a14380):

make -j1 check: 153.7s (68.1s byte-compilation, 85.6s execution) vs 135.8s 
(58.1s byte-compilation, 77.7s execution)
make -j4 check: 151.0s (67.5s byte-compilation, 83.5s execution) vs 132.3s 
(57.3s byte-compilation, 75.0s execution)
make -j8 check: 149.2s (65.5s byte-compilation, 83.7s execution) vs 130.3s 
(55.8s byte-compilation, 74.5s execution)

These numbers are the average of 20 runs in sequence, on an unloaded 
up-to-date Debian bookworm machine.

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