Recently it was proposed to make a new LIST_APPEND opcode, and several
contributors pointed out that adding opcodes to Python is always a dicey
business because it may hurt performance for obscure reasons, possibly
related to the size of that 'switch' statement.
To that end, I notice that there are several opcodes which could easily
be converted into function calls. In my code, these are not typically
performance-critical opcodes (with approximate ceval.c line count):
BUILD_CLASS # 9 lines
MAKE_FUNCTION # 20 lines
MAKE_CLOSURE # 35 lines
PRINT_EXPR # 21 lines
PRINT_ITEM # 47 lines
PRINT_ITEM_TO # 2 lines + fallthrough
PRINT_NEWLINE # 12 lines
PRINT_NEWLINE_TO # 2 lines + fallthrough
Instead, each of these would be available in the code objects co_consts
when necessary. For example, instead of
LOAD_CONST 1 (<code object g at 0x40165ea0, file "<stdin>", line 2>)
MAKE_FUNCTION 0
STORE_FAST 0 (g)
you'd have
LOAD_CONST 1 (type 'function')
LOAD_CONST 2 (<code object g>)
LOAD_GLOBALS # new opcode, or call globals()
LOAD_CONST 1 ("g")
CALL_FUNCTION 3
Performance for these specific operations will certainly benchmark worse,
but maybe getting rid of something like 150 lines from ceval.c would
help other things by magic. The new LOAD_GLOBALS opcode would be less
than 10 lines.
No, I don't have a patch. I assume each and every one of these opcodes
has a staunch defender who will now come to its aid, and save me the
trouble.
Jeff
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