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/046174.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?Guido van Rossum guido at python.org
Thu Jul 15 03:47:29 CEST 2004
> 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.

At the cost of an extra pointer dereference and jump, and usually for
naught (the uses of LOAD_CONST not in a return statement must
certainly vastly outnumber those in return statements).

Have you timed this?  I doubt you can measure a consistent performance
increase across platforms.

--Guido van Rossum (home page: http://www.python.org/~guido/)
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