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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Feb 04, 2022 at 14:06:39 +0200, Eli Zaretskii wrote:
> > Date: Fri, 4 Feb 2022 11:57:21 +0000
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, mattiase@acm.org,
> >   Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Compilation _does_ do things differently.  It runs with
> > symbols-with-pos-enabled bound to t, which makes EQ slower than when
> > that variable is nil.  To see this, have a look at the defition of
> > lisp_h_EQ in src/lisp.h, around line 372.

> Can you explain why we need to complicate EQ so much to account for
> symbols-with-pos?

There are four possible ways the two Lisp objects might match - each
object can be either a bare symbol, or a symbol with pos, giving four
possibilities.  It's worth noting that the last three possibilities are
cut off completely by the check on symbols-with-pos-enabled, except
during compilation.

Specific questions:

>   . comparison of a symbol and symbol-with-pos should only compare the
>     symbol part, and disregard the "pos" part, right?
>   . if so, couldn't we implement symbol-with-pos as a struct that has
>     the symbol at its beginning, and then use memcmp to compare only
>     that part?

> Or what am I missing?

I don't think we can get anywhere that way.  What gets compared in EQ
are the Lisp_Object's, which are typically already in processor
registers.  I don't think we typically have a pointer to memory
containing the symbol with position.  Don't forget that the position
attaches to the symbol OCCURRENCE, not the symbol itself.

-- 
Alan Mackenzie (Nuremberg, Germany).