[Python-Dev] about line numbers
Tim Peters
tim_one@email.msn.com
Thu, 12 Aug 1999 20:07:32 -0400
[Vladimir Marangozov]
> Is python with vs. without "-O" equivalent today regarding
> line numbers?
>
> Are SET_LINENO opcodes a plus in some situations or not?
In theory it should make no difference, except that the trace mechanism
makes a callback on each SET_LINENO, and that's how the debugger implements
line-number breakpoints. Under -O, there are no SET_LINENOs, so debugger
line-number breakpoints don't work under -O.
I think there's also a sporadic buglet, which I've never bothered to track
down: sometimes a line number reported in a traceback under -O (&, IIRC,
it's always the topmost line number) comes out as a senseless negative
value.
> Next, I see quite often several SET_LINENO in a row in the beginning
> of code objects due to doc strings, etc. Since I don't think that
> folding them into one SET_LINENO would be an optimisation (it would
> rather be avoiding the redundancy), is it possible and/or reasonable
> to do something in this direction?
All opcodes consume time, although a wasted trip or two around the eval loop
at the start of a function isn't worth much effort to avoid. Still, it's a
legitimate opportunity for provable speedup, even if unmeasurable speedup
<wink>.
Would be more valuable to rethink the debugger's breakpoint approach so that
SET_LINENO is never needed (line-triggered callbacks are expensive because
called so frequently, turning each dynamic SET_LINENO into a full-blown
Python call; if I used the debugger often enough to care <wink>, I'd think
about munging in a new opcode to make breakpoint sites explicit).
immutability-is-made-to-be-violated-ly y'rs - tim