> I implemented LOAD_FAST_n, STORE_FAST_n, LOAD_CONST_n for n < 16
>
> Getting a small 2% improvement in speed
> Going from about 21800 PyStones to 22300 PyStones; very hard to get
> consistent readings on the PyStones - anyone got any tips on how to get
> more consistent results under windows?
Upgrade to a real operating system. :-)
> Getting a small 3% reduction in .pyc filesizes
> os.path 24,929 unmodified
> os.path 24,149 with modifications
>
> I sort of cheated on the switch statement to avoid the use of a goto.
>
> opcode = NEXTOP();
> if (HAS_ARG(opcode))
> oparg = NEXTARG();
> ...
> switch (opcode) {
> ...
> case LOAD_FAST_14:
> case LOAD_FAST_15:
> oparg = opcode - LOAD_FAST_0;
> case LOAD_FAST:
> x = GETLOCAL(oparg);
> if (x != NULL) {
> Py_INCREF(x);
> ...
This is ok.
> I also altered the opcode.h file to use an enum for the opcodes instead
> of all those #defines. Much easier to re-arrange things that way. I have
> a feeling that most of the speedup (such that it is) comes from that
> re-arrangment, which packs the opcodes into a contiguous numeric space.
> I suspect that sorting the opcodes by frequency of access might also
> have some positive effect. Also, organising the opcodes and the switch
> statement so that frequently co-occuring opcodes are adjacent to each
> other might also have some positive effect.
Try that without the LOAD_XXX_n idea, so you can measure the effect of
each idea separately.
One problem with renumbering the opcodes is that you have to update
the "dis" module, which exports the opcodes as Python constants.
Maybe you should add some code there to regenerate the values from the
.h file, as is done in keyword.py and symbol.py.
--Guido van Rossum (home page: http://www.python.org/~guido/)
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