469,625 Members | 1,089 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,625 developers. It's quick & easy.

Performance penalty for using properties?

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
Jul 18 '05 #1
5 2750
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(getvalue)

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
Jul 18 '05 #2
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/

Jul 18 '05 #3
In article <ma**************************************@python.o rg>, 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 "accelerator" 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
Jul 18 '05 #4
In article <sl***********************@g4.gateway.2wire.net> ,
Kenneth McDonald <km********@wisc.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**@pythoncraft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk
Jul 18 '05 #5
Joe Mason wrote:
In article <ma**************************************@python.o rg>, Mike C. Fletcher wrote:

Kenneth McDonald wrote:
...

Can anyone comment on the performance
costs associated with properties vs. simple attribute lookup?
....
OpenGLContext gets around this by
defining an accelerator for the __get__ method of the field properties.
What does "accelerator" 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/

Jul 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Michael Andersson | last post: by
12 posts views Thread by Fred | last post: by
4 posts views Thread by zzfreddybb | last post: by
1 post views Thread by Peter Bär | last post: by
1 post views Thread by Steve Franks | last post: by
2 posts views Thread by william.david.anderson | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.