emacs-devel
[Top][All Lists]
Advanced

[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:26:44 +0000

Hello, Eli.

On Sun, Jan 16, 2022 at 17:04:15 +0200, Eli Zaretskii wrote:
> > Date: Sun, 16 Jan 2022 14:45:28 +0000
> > Cc: larsi@gnus.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Are you saying that the measured slowdown is specific to the
> > > byte-compiler, and will not affect other uses of Lisp, or affect them
> > > much less heavily?

> > Yes.  The byte compile, as expected, is more slowed down than other
> > software.  On a quick measurement of compiling comp.el, I found a
> > slowdown of around 12%

> That seems to be inconsistent with the 17% slowdown compiling the *.el
> files that Lars measured.

Or measurement error.  The coding style is likely to be quite a bit
different between gnus and comp.el.

> > > Because the byte-compiler is  just another Lisp program, it doesn't in
> > > general do anything an arbitrary Lisp program won't do.

> > It does.  It runs with symbols with position activated, so any operation
> > involving an EQ which doesn't match is going to be significantly slower.

> But EQ is not specific to the byte-compiler, is it?

> > > Can you show a profile where this could be seen quantitatively?

> > I'm not sure I understand.  The slowdown in the byte compiler is
> > distributed throughout the Emacs C Code.  It doesn't happen at any
> > particular isolated place.

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

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]