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?
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With