Ben North <ben@redfrontdoor.org> wrote:
Josiah Carlson:
My only concern with your propsed change is your draft implementation. [...]
Specifically, your changes to ceval.c and the compiler may have been easier to implement, but it may negatively affect general Python performance. Have you run a recent pystone before and after the changes?
I hadn't done so, no, but have now tried some tests. In fact, there is some evidence of a slight negative effect on the general performance. On my laptop, repeated pystone runs with 100,000 loops are quite variable but there might be a performance penalty of around 1% with the new code. I'm a bit puzzled by this because of course the new opcodes are never invoked in the pystone code --- does a switch statement become slower the more cases there are? (I tried grouping the cases with the new opcodes all together at the end of the switch, but the noisiness of the pystone results was such that I couldn't tell whether this helped.) Or is it just that the core bytecode-interpretation loop is bigger so has worse processor cache performance?
There have been a few examples where nontrivial blocks of code inserted into the mainloop of ceval.c slowed down Python. Indeed, it turns out that Python fit into the processor cache *just right*, and with much more, the cache was blown. Then again, 1% loss isn't really substantial, I wouldn't worry too much. Get a PEP number and talk to others in python-dev, put your patch up on sourceforge so that people on other platforms can test it out (and verify the 1% loss, if any), and if you are curious, then try out the idea I offered up - which has the potential to slow down *all* attribute lookups (though minimizes the source additions to the ceval.c mainloop).
On the other hand, getting/setting dynamic attributes seems to be about 40--45% faster with the new syntax, probably because you avoid the lookup of 'getattr' and the overhead of the function call.
That speedup sounds reasonable.
Anyway, I'll experiment with the other implementation suggestions made by Josiah, and in the meantime summarise the discussion so far to python-dev as suggested by Guido.
Great! I look forward to seeing this in Python 2.6 . - Josiah