[Python-Dev] Who cares about the performance of these opcodes?

[Jeff Epler]

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