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

[Alan Mackenzie]

Hello, Gregory.

On Fri, Feb 04, 2022 at 00:11:46 +0000, Gregory Heytings wrote:

> >>> More importantly, I wonder how slowing down EQ by a factor of 2 can 
> >>> end up costing 10% of runtime when running the test suite.  I think 
> >>> this deserves investigation.

> >> Do you have an idea how this could be investigated?

> > Usually such slowdown don't come from everywhere at the same time. So 
> > you need to "slice" our total time into subelements, and presumably some 
> > of those elements show a higher slowdown, so you can focus on those and 
> > start slicing them further.

> > As you get closer to the source, the slowdown should become more marked.


> You were too optimistic.

> I just finished a detailed analysis of the slowdown of the execution of 
> Emacs' test suite, and it turns out that the slowdown is indeed spread 
> over all tests.

> I attach the detailed results for each of the 389 tests.  Each test has 
> been executed 2000 (two thousand) times, again on an unloaded up-to-date 
> Debian bookworm computer.

Just for completion's sake, that was presumably without native
compilation.

> If you look closer at the results, you will see that the slowdown is 
> actually worse than 10%.  The slowest of all tests (lisp/net/tramp-tests) 
> is only 2% slower, because it uses external processes and is therefore not 
> as much affected as other tests by the slowdown of bytecode execution 
> itself.  If you remove that test from the calculations, you will see that 
> the slowdown is actually 17%, that is, the same slowdown as that of byte 
> compilation.

> (FWIW, I was puzzled by the claim that byte compilation could be slowed 
> down markedly, and that at the same time general bytecode execution would 
> not.  Byte compilation does not do anything that is fundamentally 
> different from general bytecode execution.)

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.

> My conclusion is that this merge should be backed out.  Its performance 
> impact has not been properly resolved and assessed.

These commits fixed a long standing bug, namely the outputting of wrong
position information in compiler warning messages.  Perhaps you could
propose a better way of fixing that bug.  For the record, I don't
believe there is a better way which is practical.

Also, there is something strange about the speed measurements on the
test suite that gives such marked slowdowns.  On measurements of "real"
Emacs activities which don't involve compilation, the slowdowns measured
were "no measurable difference", 1% and 3%.

Perhaps you could hypothesize why there is such a large speed difference
in those tests, but not in real Emacs use.  Such an understanding could
be useful.  My guess is that there is an unusually large number of `eq's
in the test suite, and that it does very little garbage collection or
I/O.

-- 
Alan Mackenzie (Nuremberg, Germany).