Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is Property execution slower than Field or Method execution?

In CLR via CSharp chapter 10 "Properties" Jeff Richter writes:

A property method can take a long time to execute; field access always completes immediately. A common reason to use properties is to perform thread synchroni- zation, which can stop the thread forever, and therefore, a property should not be used if thread synchronization is required. In that situation, a method is preferred. Also, if your class can be accessed remotely (for example, your class is derived from System.MarshalByRefObject), calling the property method will be very slow, and therefore, a method is preferred to a property. In my opinion, classes derived from MarshalByRefObject should never use properties.

Is this the case even if the property is defined to just return the private field? Why is a Method preferred in synchronization? and why is a Method preferred in MarshalByRefObject scenario?

To clarify my question:
Jeff seems to be making a blanket statement that Properties are not advisable, and that methods are preferable in those 2 scenarios. as Joe White pointed out, properties can have arbitrary code. But methods can run the same arbitrary code. That's the part i'm having difficulty with. Is there actually advantage in using methods over properties (given the same code is used) for synchronization or marshaling, or does he merely have a problem with language convention?

like image 795
Sonic Soul Avatar asked Feb 06 '12 14:02

Sonic Soul


3 Answers

I think he's making the point that, because a property can run any arbitrary code, the calling code shouldn't assume that it will finish immediately.

If all the property does is return a field, then its method body will actually be inlined by the JIT compiler and it'll be just as fast as a field access. So it's not that properties are somehow slower; it's that they're black boxes. If you don't know how a property is implemented, you can't make assumptions about it returning quickly.

(That said, making a slow property would be a clear violation of the .NET Framework Design Guidelines, specifically this one: "Do use a method, rather than a property, [if the] operation is orders of magnitude slower than a field set would be".)

As for his suggestion of using methods instead, I can't make any sense of that. Properties are methods: the property getter is a method (typically named get_PropertyName), and the property setter is a method (set_PropertyName), and code that reads the property is compiled to code that makes a method call to get_PropertyName. There's nothing special that would make a property any slower than a method.

like image 72
Joe White Avatar answered Nov 20 '22 02:11

Joe White


I think the point is that property access looks like a field access, so people don't expect anything unusual.

If you have a property that can take a long time, you should rewrite it into a method. It won't make your code perform any better, but it will be more clear that it might take a long time.

As far as performance goes, there is no difference between property access and method call. Actually property access is just a method call.

like image 33
svick Avatar answered Nov 20 '22 02:11

svick


A Method is not faster than a property, but a method is not expected to be as fast as a property. So the method is preferred to make clear that it might take some time (because of thread synchronization in this case).

Fields are not "executed" at all. Accessing a field is directly accessing memory.

like image 26
Stefan Steinegger Avatar answered Nov 20 '22 03:11

Stefan Steinegger