[Python-Dev] Opcode cache in ceval loop

[Yury Selivanov]

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