[Python-Dev] seeing off SET_LINENO

[Michael Hudson]

Tim Peters <tim.one@comcast.net> writes:

> I've been telling people at Zope Corp that getting rid of SET_LINENO would
> speed pystone (which is said to be a good predictor of Zope performance) by
> at least 7%.  If you can fudge up a test showing that, your performance work
> will be complete.

It's about 5%:

$ ../../build/python pystone.py 
Pystone(1.1) time for 100000 passes = 8.11
This machine benchmarks at 12330.5 pystones/second
$ ../../build/python pystone.py 
Pystone(1.1) time for 100000 passes = 7.69
This machine benchmarks at 13003.9 pystones/second

I can run the vanilla pystone whilst compiling or something if you
like :)

As I said, my patched Python is much more variable in pystone than
before.  I'm going to try invoking the Cache Effect Demon on this one,
unless someone can come up with a real explanation.

> [Guido]
> > ...
> > 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'm really not the best person for this, since, e.g., I never use the
> debugger, so couldn't personally care less if it stopped working <0.9 wink>.
> 
> The patch set looks very complete, so I'd encourage a checkin if nobody
> objects.
> 
> I have one objection, but it's kind of vague:  Michael, you're taking too
> much delight in how obscure this is!

It's the old boys club effect: I worked damn hard to get to the point
of understanding this stuff, so everyone else should bloody well have
to too!

>  Two examples:
> 
> + 	int instr_ub = -1, instr_lb = 0; /* for tracing */
> 
> It takes a lot of effort to reverse-engineer that the line number has
> changed if and only if
> 
>     not instr_lb <= current_bytecode_offset < instr_ub
> 
> -- or at least to reverse-engineer that this is what you believe <wink>.
> Paste the above in as a comment and save the next person the pain.  I got
> hung up the first 5 minutes guessing that "lb" and "ub" referred to "lower
> byte" and "upper byte".

Ah, OK.  Actually, taking the tracing code out of line makes me feel
less uneasy about adding hundred+ line comments explaining what's going
on.

> The other example:
> 
> + 			/* I (mwh) will gladly buy anyone a beer who
> + 			   can tell me off the top of their head why
> + 			   the exception for POP_TOP is needed... */
> 
> That's not going to be amusing two years from now when your unstated
> reasoning is no longer true, and this code breaks.  Then someone will have
> to guess what you thought you meant by this comment, whether your reasoning
> was correct at the time, and what may have changed to invalidate it.  Rather
> than tease, just explain why POP_TOP must be an exception.  If you don't
> know why, I'll buy *you* a beer <wink>.

All I can say is that I'd been driven insane by co_lnotab and
Python/compile.c when I wrote that comment <wink>.

Cheers,
M.

-- 
  I'm okay with intellegent buildings, I'm okay with non-sentient
  buildings. I have serious reservations about stupid buildings.
     -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)