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

[Alan Mackenzie]

Hello, Stefan.

On Tue, Jan 25, 2022 at 08:27:55 -0500, Stefan Monnier wrote:
> > 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.

> I highly doubt reality is that simple because CPU performance is a lot
> more complex than just counting instructions.

OK, but as a first estimate, it should do as an explanation.

> > When one of the operands is a literal nil, there is no increase in
> > execution time.

> That's an oversimplification as well: it's only when we use the `NILP`
> macro that the extra cost is avoided.  Any use of `EQ` is still slowed
> down when it happens to receive a nil as one of the arguments.

I think, but I'm not quite sure, that a literal nil gets handled by
BASE_EQ rather than EQ, or this might depend on it getting native
compiled.

> 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.

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

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).