[Python-ideas] New syntax for 'dynamic' attribute access

[Josiah Carlson]

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 .

 - Josiah