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

[Eli Zaretskii]

> Date: Sun, 16 Jan 2022 15:26:44 +0000
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I thought the slowdown was in Lisp somewhere.  If it's in EQ, I'm not
> > sure I understand how come the byte-compiler's slowdown is so much
> > more significant than in other Lisp code.
> 
> The specification of the macro lisp_h_EQ in lisp.h L370 starts off:
> 
> #define lisp_h_EQ(x, y) ((XLI ((x)) == XLI ((y)))       \
>   || (symbols_with_pos_enabled    \
> .....
> 
> If symbols_with_pos_enabled is currently false, EQ need never execute
> more than these first two lines.  If the variable is true, potentially
> each of the other three cases (each variable x and y can be with or
> without a position, giving four matching possibilities) needs to be
> checked individually, which is slow.
> 
> Essentially the same code is coded up as emit_EQ inside comp.c.

Yes, but my question was why would this affect the byte-compiler more
than it affects any other arbitrary Lisp.  Are you saying that the
byte-compiler is such a more intensive user of EQ than other Lisp
programs?