[Python-Dev] Opcode cache in ceval loop (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Mon Feb 1 17:12:14 EST 2016

Andrew,

On 2016-02-01 4:29 PM, Andrew Barnert wrote:

Looking over the thread and the two issues, you've got good arguments for why the improved code will be the most common code, and good benchmarks for various kinds of real-life code, but it doesn't seem like you'd tried to stress it on anything that could be made worse. From your explanations and your code, I wouldn't expect that @classmethods, functions stored in the object dict or generated by getattr, non-function callables as methods, etc. would go significantly slower,

Right. The caching, of course, has some overhead, albeit barely detectable. The only way the slow down might become "significant" if there is a bug in the ceval.c code -- i.e. an opcode doesn't get de-optimized etc. That should be fixable.

or code that mixes @properties or getattr proxy attributes with real attributes, or uses slots,

No performance degradation for slots, we have a benchmark for that.
I also tried to add slots to every class in the Richards test - no improvement or performance degradation there.

or code that does frequently write to a global, etc. But it would be nice to know that they don't instead of just expecting it.

FWIW I've just tried to write a micro-benchmark for getattr: https://gist.github.com/1st1/22c1aa0a46f246a31515

Opcode cache gets quickly deoptimized with it, but, as expected, the CPython with opcode cache is <1% slower. But that's a 1% in a super micro-benchmark; of course the cost of having a cache that isn't used will show up. In a real code that doesn't consist only of LOAD_ATTRs, it won't even be possible to see any slowdown.

Thanks, Yury

More information about the Python-Dev mailing list