SET_LINENO

[Martin v. Löwis]

Bruce Dawson <bruce_deletethis_dawson at cygnus-software.com> writes:

> Executive summary: Has the SET_LINENO removal been tested with the HAP
> debugger, and wouldn't a breakpoint instruction give much larger
> benefits?

To my knowledge: no, and no.

> It *sounds* like it has been done in such way to not cause debugger
> problems, but I'm curious if anyone has tested HAP with 2.3.

It was definitely designed to not cause problems for debuggers. If you
want to find out, you probably can easily test it yourself.

> Also, it sounds like the reason for removing SET_LINENO was to improve
> the performance of Python scripts. 

Correct.

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

I think this suggestion is incorrect; the improvements can be
demonstrated.

> It seems to me (from the sidelines/peanut gallery/wherever) that the
> biggest performance problems in the SET_LINENO area are when
> debugging, not when running free, and that therefore this optimization
> is targeting the lesser problem.

No. Performing the SET_LINENO instruction if there is no debugging
going on contributed significantly to execution speed, which is the
reason for not emitting them under -O.

> So, wouldn't a break-point opcode be a more substantial improvement
> than removing SET_LINENO? Just bringing up that old topic again to see
> if it gets any more traction :-)

No. Removal of SET_LINENO does improve performance in a "free-running"
application, which adding a breakpoint instruction would not.

That said: it might be still worthwhile to add a breakpoint
instruction. There are a number of issues to be considered, such as
getting the breakpoint instruction into the byte code, and getting the
original instruction back in. So if you'ld like to see one, you
probably have to write a PEP.

> P.P.S. A breakpoint instruction would also be a boon for asserts - I'd
> love to be able to stop on the assert when running under a debugger,
> to see what is wrong before the stack frame unwinds.

I can't see how this helps. Wouldn't you have to set a breakpoint on
all asserts for that? And wouldn't that require finding all asserts in
the first place?

Regards,
Martin