[Python-Dev] Why is Bytecode the way it is? (original) (raw)
Raymond Hettinger python at rcn.com
Thu Jul 8 02:16:51 CEST 2004
- Previous message: [Python-Dev] Why is Bytecode the way it is?
- Next message: [Python-Dev] Why is Bytecode the way it is?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Why does the RETURNVALUE opcode have to return something from the stack? Why not have a RETURNVAR opcode that would directly return a variable or constant? (a leading bit could indicate whether to look in the const or var tuple).
If the goal is speed, there isn't much to be had. LOAD_CONSTANT is blazingly fast and the goto fast_next_opcode cheapens the cost of the trip around the eval loop.
The eval loop is already pretty tight. Short of moving to a direct threading model or some such, the only remaining big boost would be to move all the tracing/profiling mumbo-jumbo into a separate eval function.
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.
To a lesser extent, there is some pay-off to localizing global lookups. My experiments show there is only about a 5% total gain to be had. Localizing is easy; determining what can safely be localized is a briarpatch.
Raymond
- Previous message: [Python-Dev] Why is Bytecode the way it is?
- Next message: [Python-Dev] Why is Bytecode the way it is?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]