Speed of attribute lookup (was Re: advice on programming style: is multiple inheritance bad?)

Aahz aahz at pythoncraft.com
Fri Feb 20 02:12:05 CET 2004

In article <n282209gef37juq7j248otjg0qsp5l5is2 at 4ax.com>,
Greg Chapman  <glc at well.com> wrote:
>On 1 Feb 2004 22:42:56 -0500, aahz at pythoncraft.com (Aahz) wrote:
>>The problem with attribute lookup in new-style classes is that any
>>instance attribute could be a property.  So if Python finds an attribute
>>on the instance, it needs to traverse the MRO to check if there's a
>>property.  If there isn't one, that's an expensive waste.
>>Guido, Ping, and I worked on a patch to fix that at last year's PyCon
>>sprint, but one common case slowed down enough that Guido vetoed the
>>patch.  Anyone who wants to bring fresh eyeballs would be welcome.
>>(Don't remember the precise specifics off-hand, but I'm willing to work
>>with someone who wants to try.)
>I assume the work you did last year is the cache-attr-branch in the
>CVS?  Is there some documentation somewhere that more fully describes
>the reasons for your approach (and possibly rejected alternatives)?

That's the patch.  Unfortunately, I don't think there's much doc.

>I wonder if you considered turning off the cache for types with
>no instance dict (tp_dictoffset == 0)?  The slowdown in access to
>attributes defined in the first class in the mro is probably most
>critical for built-in types (without instance dicts), which access both
>methods and data using class attributes.  For types implemented in
>Python, I for one would be willing to trade some slow down in accessing
>class attributes (generally a prelude to making a Python function
>call, which is going to be relatively slow anyway), for a speed up in
>accessing instance attributes.

That's what I thought, too, but there was some reason Guido wasn't
willing to live with that, which I can't remember.
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach

More information about the Python-list mailing list