[Python-Dev] seeing off SET_LINENO

[Tim Peters]

[Michael Hudson]
> ...
> 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%

Great!!

> (Nearly 25% speed up since 221?  Boggle.  Some of this may be compilation
> options, I guess)

No, it's the new sort implementation -- it's truly magical <wink>.

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.

[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!  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".

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