[Python-Dev] seeing off SET_LINENO

[Michael Hudson]

Guido van Rossum <guido@python.org> writes:

> > Here goes.  Everything is relative to 221-base, which is 2.2.1 from Sean's 
> > RPM.  This is the slowest, so all percentages are negative, and more 
> > negative is better.  I hope the names are obvious.
> > 
> > 221-base             +0.00% (obviously)
> > 221-O-base:          -9.69%
> > CVS-base:           -15.43%
> > CVS-O-base:         -23.56%
> > CVS-hacked:         -23.66%
> > CVS-O-hacked:       -23.70%
> > 
> > (Nearly 25% speed up since 221?  Boggle.  Some of this may be compilation 
> > options, I guess)
> 
> No, pymalloc sped us up quite a bit.

Yes, this occurred to me after I posted.

pystone is a mystery.  It's a fair bit slower but also much more
variable with my patch.  Moving trace code out of line helps quite a
bit but it's still ~1% slower.

> > Anyway, it seems I haven't slowed -O down.  At some point I might try 
> > moving the trace code out of line and see if that has any effect.  Not 
> > today.

Did do this yesterday, in fact.  As I said, it helped pystone a bit,
so I'll upload a separate patch to sf.

[...]
> What's the next step?  I haven't had time to review your code.  Do you
> want to check it in without further review, or do you want to wait
> until someone can give it a serious look?  (Tim's on vacation this
> week so it might be a while.)

I think I'd like to wait for serious review.  I'd be surprised if the
patch went out of date at all quickly.

Also, it seems Lib/compiler currently works by generating SET_LINENO
and then builds co_lnotab by scanning for them afterwards.  That's not
going to work in the new world, so I should probably think about how
to change it...

Cheers,
M.

-- 
  Finding a needle in a haystack is a lot easier if you burn down
  the haystack and scan the ashes with a metal detector.
      -- the Silicon Valley Tarot (another one nicked from David Rush)