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

[Stefan Monnier]

>> 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 don't think that's the case of C code that says

    EQ (Qnil, ...)

maybe it is the case for ELisp code that says (eq nil ...) and which
gets native compiled.  But I suspect it's a very small proportion of
the uses of EQ/eq, in any case.

Of course there shouldn't be very little code that says `EQ (Qnil, ...)`
because such code should use `NILP` instead (and *that* code indeed
doesn't suffer from the slowdown).

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

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.

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

Mind you, I consider 2½% to be already quite different from "about 1%",
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.


        Stefan