Performance penalty for using properties?

[Kenneth McDonald]

Now that I'm back to Python and all the new (to me) cool features,
I find I'm using properties a lot, i.e. I'm defining:

foo = property(fset=. .., fget=...)

for a number of properties, in many of my classes. I'm not using
them for anything performance critical yet, but could see myself
doing so in the future. Can anyone comment on the performance
costs associated with properties vs. simple attribute lookup?

Thanks,
Ken

[Peter Otten]

Kenneth McDonald wrote:

Now that I'm back to Python and all the new (to me) cool features,
I find I'm using properties a lot, i.e. I'm defining:

foo = property(fset=. .., fget=...)

for a number of properties, in many of my classes. I'm not using
them for anything performance critical yet, but could see myself
doing so in the future. Can anyone comment on the performance
costs associated with properties vs. simple attribute lookup?

It seems I'm becoming obsessed with timeit.py :-)

<property.py>
class Test(object):
def getvalue(self):
return self._value
value = property(getval ue)

t = Test()
t._value = 123
</property.py>

$ timeit.py -s"from property import t" "t._value"
1000000 loops, best of 3: 0.207 usec per loop
$ timeit.py -s"from property import t" "t.getvalue ()"
1000000 loops, best of 3: 0.918 usec per loop
$ timeit.py -s"from property import t" "t.value"
1000000 loops, best of 3: 1.03 usec per loop

Roughly factor five, most of the time being consumed by the implied function
call.

Peter

[Mike C. Fletcher]

Kenneth McDonald wrote:
....

Can anyone comment on the performance
costs associated with properties vs. simple attribute lookup?

They can become a significant fraction of total run-time, and often wind
up showing as the heaviest methods in an entire application if they are
used pervasively (i.e. every attribute of every object is a property).
Even short runs of small systems so designed can give you 100s of 1000s
of calls to an individual method. OpenGLContext gets around this by
defining an accelerator for the __get__ method of the field properties.
At present BasicProperty doesn't have an equivalent accelerator (it has
far more "hooks" in the get methods), but I'll likely wind up coding one
eventually.

The real problem is the getters, by the way, by far the most common
situation is where you just want to alter the value or the name of the
dictionary key at which it is stored. The setters tend to be far less
frequently called in my experience, so you can leave them as python code
quite readily.

HTH,
Mike

_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

[Joe Mason]

In article <ma************ *************** ***********@pyt hon.org>, Mike C. Fletcher wrote:

Kenneth McDonald wrote:
...

Can anyone comment on the performance
costs associated with properties vs. simple attribute lookup?

They can become a significant fraction of total run-time, and often wind
up showing as the heaviest methods in an entire application if they are
used pervasively (i.e. every attribute of every object is a property).
Even short runs of small systems so designed can give you 100s of 1000s
of calls to an individual method. OpenGLContext gets around this by
defining an accelerator for the __get__ method of the field properties.

What does "accelerato r" mean in this context? Obviously, it's something
that speeds up __get__ calls, but ihow is that accomplished?

If it's a simple wrapper, that means you can blissfully ignore property
costs until profiling shows it's a problem, which is a big win.

Joe

[Aahz]

In article <sl************ ***********@g4. gateway.2wire.n et>,
Kenneth McDonald <km********@wis c.edu> wrote:

Now that I'm back to Python and all the new (to me) cool features,
I find I'm using properties a lot, i.e. I'm defining:

foo = property(fset=. .., fget=...)

for a number of properties, in many of my classes. I'm not using
them for anything performance critical yet, but could see myself
doing so in the future. Can anyone comment on the performance
costs associated with properties vs. simple attribute lookup?

That's sort-of not the point. Yes, plain attribute lookups are going to
be faster because they don't involve a function call. OTOH, new-style
classes already pay a penalty for properties because any simple
attribute lookup on an instance requires checking the whole MRO to make
sure there isn't a property. Finally, the proper comparison is against
getter/setter methods, which properties encapsulate nicely.
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Mike C. Fletcher]

Joe Mason wrote:

In article <ma************ *************** ***********@pyt hon.org>, Mike C. Fletcher wrote:

Kenneth McDonald wrote:
...

Can anyone comment on the performance
costs associated with properties vs. simple attribute lookup?

....
OpenGLConte xt gets around this by
defining an accelerator for the __get__ method of the field properties.
What does "accelerato r" mean in this context? Obviously, it's something
that speeds up __get__ calls, but ihow is that accomplished?

Accelerator in this context is a small C-coded Python extension with two
functions. One is a utility to retrieve a given key from an object's
__dict__. The other implements the __get__ operation (including lookup
of default method on the property on value lookup failure failure). All
told about 100 lines of C code.

http://cvs.sourceforge.net/viewcvs.p....c?view=markup

(and yes, I know accelerate is mis-spelled in the module names :) ).
If it's a simple wrapper, that means you can blissfully ignore property
costs until profiling shows it's a problem, which is a big win.

That's been my experience. I coded the entire VRML97 scenegraph engine
without the accelerator module and only added it when profiling showed
that the __get__ method was a hot-spot for performance. The
non-accelerated code is still there in case the C module isn't
available, of course. As I said, haven't gotten to the
accelerator-writing stage yet with BasicProperty, but I expect to soon.

Have fun,
Mike

_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/