[Python-Dev] SET_LINENO and python options

[Tim Peters]

[Ken Manheimer]
> ...
> (Maybe i'm misremembering, but i recall that removing SET_LINENO
> didn't yield a whole lot of performance improvement.

That's correct, it's rarely more than just a few percent.

> Actually, i have the impression it's been a canonical example of
> how casual optimizations don't do what you expect - but i may be
> off base here.)

Well, it did what *I* expected <wink>.  There are the "state lottery" and
"penny saved is a penny earned" schools of optimization.  They appeal,
respectively, to "no guts, no glory" and "slow and steady wins the race"
types.  Both are valuable, although the true merits of the latter don't
become apparent until after it's been pursued consistently for years.
Python hasn't done that (there's been no consistency of effort, just manic
"speed it up" bursts), and neither has it pursued any Major Schemes since
LOAD_FAST was introduced.  The most interesting dropped project "in the
middle" was Skip Montanaro's Rattlesnake, which aimed to change the VM from
a stack to a register model.

> I see the ability to debug at whim, even when you didn't expect having
> to do so, as being a major win, part of the incremental development
> process.

Same here!  But I'm a little warped <snort>:  I worked on optimization for a
living for so many years, that one reason I was attracted to Python is that
it didn't do *any* optimization to screw up my view of what my code was
doing.  Any debugger that claims to work well with "for real" optimized code
in any language is lying.  So the only optimizations I've ever supported in
default-mode Python are things the user can't detect via semantics or
usability.  So I'm also -1 on

[Vladimir]
> 1) python         - code without SET_LINENO
> 2) python -g      - code for debugging, with SET_LINENO
> 3) python -O      - code without doc-strings.

unless SET_LINENO isn't needed for debugging.  The speedup -O yields today
is real and consistent, but rarely makes a difference worth worrying about
(the only times it's mattered for me were in extremely well-tested CPU-bound
programs that I intended to run for days straight, and then I appreciated
the few hours it saved).

python-the-choice-for-a-slow-generation<wink>-ly y'rs  - tim