[Python-Dev] Why is Bytecode the way it is? (original) (raw)

Nick Bastin nbastin at opnet.com
Thu Jul 15 00:01:14 CEST 2004

On Jul 10, 2004, at 12:55 AM, Chris King wrote:

While recently goofing around with the bytecode, I thought of doing something like this:

case LOADCONST: x = GETITEM(consts, oparg); PyINCREF(x); + if (*nextinstr == RETURNVAL) { + retval = x; + why = WHYRETURN; + goto fastblockend; + } PUSH(x); goto fastnextopcode; This would skip the stack and a trip through the loop without changing the parser or the bytecode, and with a minimal amount of added code or overhead. This could (of course) be applied to other opcodes, too.

This seems unlikely to have any effect whatsoever. I would venture that the vast majority of LOAD_CONST found in compiled bytecode would be for the implicit 'return none', which oftentimes never gets executed anyhow, because it follows an explicit RETURN_VALUE. A cursory run through some python I have here indicates that of the LOAD_CONST instructions that are actually executed, very few are followed by a RETURN_VALUE (usually a BINARY_ADD, or STORE_FAST, or the like).

Applying it to other opcodes (like what, LOAD_FAST?) seems like a bad idea, since my past experience with profiling the main interpreter loop tells me that a majority of the trailing opcodes would have to be predicted correctly to offset the expense of the check, and I don't know if that's possible. Obviously, if someone can find a strong correlation, great, but I don't think this is one.

-- Nick

More information about the Python-Dev mailing list