> Why does the RETURN_VALUE opcode have to return something from the > stack? Why not have a RETURN_VAR 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
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