A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-July/046166.html below:

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

[Python-Dev] Why is Bytecode the way it is? [Python-Dev] Why is Bytecode the way it is?Skip Montanaro skip at pobox.com
Thu Jul 15 01:31:38 CEST 2004
    Chris> While recently goofing around with the bytecode, I thought of
    Chris> doing something like this:

    Chris>   case LOAD_CONST:
    Chris>       x = GETITEM(consts, oparg);
    Chris>       Py_INCREF(x);
    Chris> +     if (*next_instr == RETURN_VAL) {
    Chris> +         retval = x;
    Chris> +         why = WHY_RETURN;
    Chris> +         goto fast_block_end;
    Chris> +     }
    Chris>       PUSH(x);
    Chris>       goto fast_next_opcode;

    Chris> This would skip the stack and a trip through the loop without
    Chris> changing the parser or the bytecode, and with a minimal amount of
    Chris> added code or overhead. 

You'd have to test it.  You'd speed up getting to the return point at the
expense of slowing down every other LOAD_CONST instruction.

Skip
More information about the Python-Dev mailing list

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