Raymond Hettinger wrote: >... > The eval loop is already pretty tight. Compared to what? Total runtime of Python programs? Psycho? Java implementations? I suppose the statement is based on the observation that compiling away the eval loop by using Pyrex or Python2C results in very little speed gain. > As for tweaking opcodes, the biggest remaining wins are in LOAD_ATTR and > CALL_FUNCTION. They've been specialized enough that making further > improvements is non-trivial. I'm really not even proposing a change to Python as much as trying to understand why it is the way it is. I can see how a stack is helpful for evaluating deeply nested expressions (although temporary variables seems another good valid approach). I just don't see the payoff for shuffling variables from locals onto the stack and back into the locals table. Paul Prescod
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