[Python-ideas] New syntax for 'dynamic' attribute access
jcarlson at uci.edu
Sun Feb 11 11:39:16 CET 2007
Ben North <ben at 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 .
More information about the Python-ideas