Re: Excessive use of `eassert`

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 19 Jan 2024 08:01:47 -0500
> 
> >> shows that `make_lisp_symbol` is not inlined, so NILP(x) ends up being
> >> an actual function call to a function calling another function ....
> >> which I think is definitely in the "excessive" camp :-)
> >
> > I'm not sure I follow.  Can you elaborate?  Are you saying that the
> > assertion causes make_lisp_symbol not to be inlined?  And what
> > functions are called by NILP?
> 
> 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?  We've had that assertion
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.

> >> The patch below seems to address this specific issue, tho I haven't
> >> measured its performance impact yet.
> > Is this specifically about NILP?  Or are there other situations where
> > this assertion slows us down considerably.  I wouldn't want to drop
> > this assertion so summarily, if possible.
> 
> 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.  Perhaps especially so now that we have
symbols-with-positions as well as bare symbols.

I have added Paul, who introduced that assertion (and the code around
it).  Paul, do you think this assertion is important to keep?

I also added Alan, in case he has comments.