Is there a performance difference between properties vs. backing fields in read/write operations?

Question

When working within a class on its own fields and properties, I typically only use the property when it performs some function (like limiting a value or validating or whatever). Otherwise I prefer to read/write the backing field directly.

I somehow got it in my head that this would be a more generally performant way to do things, but it occurred to me that I don't really have any evidence to support this idea.

Aside from convention or taste, is there an actual performance factor between one and the other methods?

Answer 1

If the property is a straight get/set its compiled away - in other words, the compiler will turn either using the property or the field directly into the same thing - so no performance difference.

However, get/sets can incorporate whatever logic they want so can be expensive - however, guidelines often advise keeping them light.

Properties have a few benefits, even if they are just get/set covers:

• Data binding can only see properties, not fields.
• It keeps with the concept of encapsulation.
• You can enforce read only or write only semantics.
• You can apply attributes separately to the underlying field (useful in serialisation scenarios).

Just as an aside, although it is interesting to review the minute performance characteristics of these things - in production code applying this type of optimisation (well, in this case there isn't one) would likely come under the banner of premature optimisation.

Answer 2

There shouldn't be a difference in performance. If you use Reflector to look at the disassembly of the code, it automatically creates the backing field for you in the simplest way. It's really just syntactic sugar your compiler provides for you to make life easier.

Answer 3

It really depends. Technically it could be slower, but even in those cases it will be almost imperceptable. Here are the rules for how method inlining works taken from here.

• Methods that are greater than 32 bytes of IL will not be inlined.
• Virtual functions are not inlined.
• Methods that have complex flow control will not be in-lined. Complex flow control is any flow control other than if/then/else; in this case, switch or while.
• Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.
• If any of the method's formal arguments are structs, the method will not be inlined.

Since the C# compiler creates separate getter and setter methods from the property declaration they would obvious be treated independently of one another. Based on the rules above I would say most of the time property accessors are inlined. I think the rule about methods having to be nonvirtual would be one of the nontrivial showstoppers that would occur frequently though.