Performance overhead for properties in .NET

Question

I read somewhere that having public properties is preferable to having public members in a class.

1. Is this only because of abstaraction and modularity? Are

Answer 1

1) Its for encapsulation principles, but other .NET features use properties such as data binding.

2) I'm not sure I agree with that, I've always heard that if the property is a straight get/set its just as fast as a standard field access - the compiler does this for you.

Update: seems to be a bit of both, compiles to method call but JIT-optimized away. Either way, this sort of performance concern is not going to have a meaningful impact on your code. However, note that the guidance around implementing properties is to make them as light-weight as possible, they are not expected by callers to be expensive.

Answer 2

Don't worry at all about the performance overhead. It is so minor that you should not consider weakening the encapsulation of the class; it would be premature optimization of the worst sort.

Answer 3

After I posted this post, I realized that it's basically for hiding the inner workings of you object.

Answer 4

Is this only because of abstaraction and modularity? Are there any other over-riding reasons?

Not that I know of; these reasons are by themselves compelling enough. But maybe someone else will jump in on this.

The property accesses are conerted into function calls by the compiler. For properties without a backup store (e.g. public string UserName { get; set; }), what would be the performance overhead compared to a direct member access? (I know it shouldn't usually make a difference but in some of my code, properties are accessed millions of times.)

In the resulting Intermediate Language, a property access is translated to a method call. However, as the word says, this is only an Intermediate Language: it gets compiled Just-In-Time down to something else. This translation step also involves optimizations like inlining of trivial methods, such as simple property accessors.

I would expect (but you'd need to test to make sure) that the JITter takes care of such accessors, so there should be no performance difference.

Answer 5

Running the test 20 times in a row, ensuring that JIT optimization is enabled in the Release build:

Time for 1 and 2 : 47,66
Time for 1 and 2 : 37,42
Time for 1 and 2 : 25,36
Time for 1 and 2 : 25,25
Time for 1 and 2 : 27,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 26,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25
Time for 1 and 2 : 25,25

Yes, the JITter is that good at inlining property accessors. Perf is a non-issue and should never be considered.

Answer 6

Make sure you're running with Ctrl-F5 instead of F5; otherwise the debugger will still attach and some optimizations may not work the same, even in Release mode. At least that's the case on my machine: F5 gives similar results to what you posted, whereas Ctrl-F5 gives equal results.