Guido van Rossum <gu...@python.org> added the comment:

So dynamically, I see about 0.5% of all opcodes are ADD_INT, so higher than 
statically (which was 0.1%) but still small enough that I'm abandoning work on 
ADD_INT.

I've got a branch where I'm adding POP_JUMP_IF_NONE and POP_JUMP_IF_NOT_NONE 
(which capture if x is None, if x is not None) but the static count there is 
still pretty low, around 0.2% statically. These numbers are remarkably stable 
-- I get 0.2% exactly for mypy, 0.18% for the stdlib. (A bit more in the 
azure-cli source code: 0.35%.)

I expect that the dynamic count here would be a bit higher too: without running 
it, I'd expect around 1%, if we take it that the average loop does about 5 
iterations -- my results for ADD_INT would lead to that conclusion, and this 
was independently verified by an Instagram blog post from 2017. 
(https://instagram-engineering.com/profiling-cpython-at-instagram-89d4cbeeb898, 
search for "loopyness")

Is that enough to persevere? I really don't know.

I have a few other potential opcode combinations, RETURN_CONST and RETURN_NONE, 
but since those (by definition) don't occur in a loop, I'm even less optimistic 
about the value of those.

We really should optimize things like LOAD_FAST + LOAD_FAST, which occurs much 
more frequently. However the way to encode that combination is pretty gross, 
and I'd rather do that another time.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue43684>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to