[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time to merge scratch/correct-warning-pos into master, perhaps?
From: |
Alan Mackenzie |
Subject: |
Re: Time to merge scratch/correct-warning-pos into master, perhaps? |
Date: |
Sun, 16 Jan 2022 15:50:16 +0000 |
Hello, Eli.
On Sun, Jan 16, 2022 at 17:43:19 +0200, Eli Zaretskii wrote:
> > 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.
It is because symbols_with_pos_enabled is bound to true inside the byte
compiler (and the native compiler), but nowhere else.
> Are you saying that the byte-compiler is such a more intensive user of
> EQ than other Lisp programs?
Sort of - it uses all ten lines of lisp_h_EQ, rather than just the first
two lines used by all the other code.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, (continued)
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Lars Ingebrigtsen, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?,
Alan Mackenzie <=
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Lars Ingebrigtsen, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Lars Ingebrigtsen, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Mattias EngdegÄrd, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Mattias EngdegÄrd, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/16