Re: Excessive use of `eassert`

[Stefan Monnier]

>> AFAICT it's worse than just `NILP`, I think, because every `Qnil` (same
>> thing with all other `Q<something>`, I guess) becomes a call to
>> `builtin_lisp_symbol` which itself has a call to `make_lisp_symbol`.
>
> Then how come this is suddenly an issue?

Oh, I don't think it's a new issue (tho maybe it is, I have no idea).
I just happened to hit `C-z` in Emacs for some unrelated reason and saw
on the stack `make_lisp_symbol` and `builtin_lisp_symbol`, which seemed
odd, so I looked a bit closer.

> since 2016.  I use an Emacs build with ENABLE_CHECKING and without
> optimizations every day, and while it is indeed slower than the
> production build by a factor of 3.5, it is not unbearably slow.

Same here.  I can't vouch for 3.5 specifically, but 3-4 sounds about
right for me as well.  Tho I'll also note that (many) years ago
the slowdown was lower, more in the 2x ballpark.

>> Why do you find this specific assertion important?  When building other
>> `Lisp_Object`s (like `make_fixnum`) we don't seem to have any
>> corresponding assertion that the revere operation (e.g. XFIXNUM) returns
>> the original value.
> make_fixnum is a trivial bit-shuffling, whereas make_lisp_symbol is
> much trickier.

`make_fixnum` does "shift + tag", whereas `make_lisp_symbol` does "add +
tag".  Doesn't seem so terribly more tricky.

> Perhaps especially so now that we have symbols-with-positions as well
> as bare symbols.

`make_lisp_symbol` doesn't touch SWPs.

In any case, I'm not insisting.  I already removed that assertion from
my local branch, which is the one that affects me.  My messages was
mostly intended to share my discovery/surprise: I always assumed that
something like `Qnil` in the source would turn into some kind of
constant in the machine code (possibly modulo relocation), regardless of
ENABLE_CHECKING.


        Stefan