[Python-Dev] LOAD_SELF and SELF_ATTR opcodes

[Phillip J. Eby]

At 09:17 AM 10/15/2005 +0100, Michael Hudson wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
>
> > Indeed, even pystone doesn't do much attribute access on the first 
> argument
> > of most of its functions, especially not those in inner loops.  Only
> > Proc1() and the Record.copy() method do anything that would be helped by
> > SELF_ATTR.  But it seems to me that this is very unusual for
> > object-oriented code, and that more common uses of Python should be helped
> > a lot more by this.
>
>Is it that unusual though?  I don't think it's that unreasonable to
>suppose that 'typical smalltalk code' sends messages to self a good
>deal more often than 'typical python code'.  I'm not saying that this
>*is* the case, but my intuition is that it might be (not all Python
>code is that object oriented, after all).

Well, my greps on the stdlib suggest that about 50% of all lines doing 
attribute access, include an attribute access on 'self'.  So for the 
stdlib, it's darn common.  Plus, all functions benefit a tiny bit from 
faster access to their first argument via the LOAD_SELF opcode, which is 
what produced the roughly 2% improvement of parrotbench.

The overall performance question has more to do with whether any of those 
accesses to self or self attributes are in loops.  A person who's 
experienced at doing Python performance tuning will probably lift as many 
of them out of the innermost loops as possible, thereby lessening the 
impact of the change somewhat.  But someone who doesn't know to do that, or 
just hasn't done it yet, will get more benefit from the change, but not as 
much as they'd get by lifting out the attribute access.

Thus my guess is that it'll speed up "typical", un-tuned Python code by a 
few %, and is unlikely to slow anything down - even compilation.  (The 
compiler changes are extremely minimal and localized to the relevant 
bytecode emission points.)  Seems like a freebie, all in all.