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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sun, Jan 16, 2022 at 16:21:54 +0200, Eli Zaretskii wrote:
> > Date: Sun, 16 Jan 2022 14:06:59 +0000
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Since this is glaringly inconsistent with the timings Alan published,
> > > I think it would be a good idea to measure the difference for each of
> > > the*.el files, because it could be that a couple of outliers skew the
> > > entire picture.  That is, put the 'time' command inside the 'do', and
> > > don't use -j8; then compare the outputs.

> > On the branch, the byte compiler is doing more work than on master.  My
> > timings from yesterday were about the speed of Emacs in daily use rather
> > than while compiling.

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

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

> Can you point to the places in the byte-compiler that do significantly
> more work on the branch?

Every EQ operation.  With symbols-with-pos-enabled set, the EQ has
appreciably more work to do.  If the first binary comparison does not
match, it needs to check the possibilities of symbols with positions.

With symbols-with-pos-enabled set to nil, an EQ has only a little more
work to do (namely, checking symbols-with-pos-enabled and finding it
unset).

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

-- 
Alan Mackenzie (Nuremberg, Germany).