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

[Gregory Heytings]

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

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

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

slowdown.csv
Description: Text Data