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
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