[Python-Dev] Why is Bytecode the way it is?

[Nick Bastin]

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 LOAD_CONST:
>      x = GETITEM(consts, oparg);
>      Py_INCREF(x);
> +     if (*next_instr == RETURN_VAL) {
> +         retval = x;
> +         why = WHY_RETURN;
> +         goto fast_block_end;
> +     }
>      PUSH(x);
>      goto fast_next_opcode;
>
> 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