Re: Excessive use of `eassert`

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Jan 19, 2024 at 17:02:06 +0200, Eli Zaretskii wrote:
> > 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.

Not really.  Symbols with positions don't belong in the obarray.  If they
somehow get there, then that's a bug to be fixed.

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

-- 
Alan Mackenzie (Nuremberg, Germany).