[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4