SET_LINENO

[Tim Peters]

[Bruce Dawson]
> However one of the posts on this topic (can't find it now) suggested
> that the hoped for improvements had not actually materialized.

[Martin v. Lowis]
> I think this suggestion is incorrect; the improvements can be
> demonstrated.

It was platform-dependent, and was a real loss on Windows.  I'm not worried
about that, though, because it's just "ceval disease":  the performance of
the eval loop goes up or down approximately at random.  MSVC6 has, for
years, done better than gcc on it, and seemingly by accident.  I figured
that MSVC had been knocked out of a local minimum by accident here, and
that, over time, other people making other random changes to ceval would
eventually nudge it pack in to the same-- or an even better --local minimum.

As of today, on a rather noisy box,

C:\Code\python\PCbuild>\python22\python -O ../lib/test/pystone.py
Pystone(1.1) time for 50000 passes = 3.81114
This machine benchmarks at 13119.4 pystones/second

C:\Code\python\PCbuild>\python22\python -O ../lib/test/pystone.py
Pystone(1.1) time for 50000 passes = 3.78183
This machine benchmarks at 13221.1 pystones/second

C:\Code\python\PCbuild>\python22\python -O ../lib/test/pystone.py
Pystone(1.1) time for 50000 passes = 3.79681
This machine benchmarks at 13169 pystones/second


C:\Code\python\PCbuild>python ../lib/test/pystone.py
Pystone(1.1) time for 50000 passes = 3.41775
This machine benchmarks at 14629.5 pystones/second

C:\Code\python\PCbuild>python ../lib/test/pystone.py
Pystone(1.1) time for 50000 passes = 3.41381
This machine benchmarks at 14646.4 pystones/second

C:\Code\python\PCbuild>python ../lib/test/pystone.py
Pystone(1.1) time for 50000 passes = 3.40596
This machine benchmarks at 14680.1 pystones/second

C:\Code\python\PCbuild>

Now lots of things have changed, but performance is so much better under 2.3
now on Windows without -O than it used to be with -O in 2.2 that "pinning
the blame" isn't an interesting game anymore.

Still, for peak speed over time, it would obviously have been better to
remove SET_LINENO via a method that *didn't* add new instructions to the
eval loop's critical path.  That was much harder to do, though.  I'm quite
happy with the compromise Michael crafted.