1

Was working with some code today that I did not write and noticed that in a class there was a private member m_privateMember. The coder had also included a method called GetPrivateMember() which contained only return m_privateMember. It is worth mentioning that this method is heavily used within the class itself as opposed to simply using the private field that is accessible in this scope.

Semantically I see a lot of things wrong with this. A method vs. an actual getter/setter seems sloppy and I've always thought that if you are within class scope it is better form to actually use the private field rather than the getter. Needless to say, I am going to clean up the code purely for the reason that it does not meet coding standards in our workplace but I was curious to know if doing so would also improve performance in any way?

Does calling a method that simply returns a private field invoke more overhead?

Jesse Carter
  • 20,062
  • 7
  • 64
  • 101
  • 2
    Calling a method does have an overhead, however the compiler would likely inline the method call anyway.. – stuartd Dec 17 '12 at 15:03
  • 1
    Unless I'm missing something, this has been asked before a number of times: http://stackoverflow.com/questions/601621/properties-vs-methods. And to clarify, from a performance view, there's not much difference between a property and a method and the argument for method/property vs field would be largely the same. – Pete Dec 17 '12 at 15:05
  • Don't properties in C# compile into methods anyway? – Adam Houldsworth Dec 17 '12 at 15:09
  • @Pete This question is focusing on performance. I wouldn't call it a dupe of your linked question. – Steven Jeuris Dec 17 '12 at 15:10
  • @Pete: OP wants to know if there's a difference in accessing a method and a private field in terms of performance. – Tim Schmelter Dec 17 '12 at 15:10
  • @Pete yes I am trying to determine if changing all of the method calls within the class that defines both the attribute and the method to simply use the private attribute will improve preformance – Jesse Carter Dec 17 '12 at 15:12
  • @JesseCarter You are talking about field members, not attributes. I adjusted your question accordingly. – Steven Jeuris Dec 17 '12 at 15:16
  • @StevenJeuris Thank you, UML Studio (which we use to generate our models) refers to them as Attributes so I assumed field and attribute could be used interchangably – Jesse Carter Dec 17 '12 at 15:19
  • My bad. Still answered, though: http://stackoverflow.com/questions/4369346/actual-performance-of-fields-vs-properties – Pete Dec 17 '12 at 15:19
  • 1
    @Pete the link you are providing still refers to an actual Property using a get/set as opposed to a method that returns the private field. The difference is subtle but its part of what prompted me to post this as I wasn't sure if a method call and a Property get were directly equivalent – Jesse Carter Dec 17 '12 at 15:21

2 Answers2

2

To answer your question directly: It depends.

A property which is just a single return private field is very likely to inlined by the compiler (when optimizations are enabled) for any calls inside that assembly. In this case, it is an identical operation to accessing the field directly.

For calls accessing the property from outside the assembly, the JIT compiler is likely to inline the call in the same way as the static compiler, but the static compiler is not allowed to do so, as it has to respect the interface provided by the assembly. This is so that you can replace a compiled assembly with a new version which has no public changes and not require a re-compile of the application source to use the new version.

As the property gets more complicated, the chances of being inlined by either the static compiler or JIT compiler become less and the property is invoked more like you would imagine.

All this said, the discussion of performance is really an academic one. In almost all practical examples, the difference between invoking the property versus reading the private field is trivial. The only time it will be measurable is if you're running on some very low-spec embedded system or doing billions of reads every second for each user of your system.

Most computers are so fast that you should be choosing the technique which makes your code more maintainable, not the one which gives you an extra 0.0000001 second decrease in execution time.

Servy
  • 202,030
  • 26
  • 332
  • 449
Paul Turner
  • 38,949
  • 15
  • 102
  • 166
1

Does calling a method that simply returns a private attribute invoke more overhead?

There's no real noticeable difference but aesthetics and proper usage here, all else being equal, as a getter and setter method is generated per property per implementation of get and set - so all calls to return the value of a thing from a property is actually a method call, although there might be some implementation factors / optimisation going on that make using properties 'better' even in terms of speed, but with negligible improvements to comparable effect for the most part.

Grant Thomas
  • 44,454
  • 10
  • 85
  • 129
  • Also don't forget that a property getter/method can execute additional logic which a private member can't - it may be that this was the original intention but was never used (I would always go the property route for this though, it seems cleaner syntactically as it isn't a method, it's a getter) – Charleh Dec 17 '12 at 15:08
  • @Charleh I understand what you're saying but not sure of the relevance. The culprit could have used a property with additional logic, even side effects, if they'd like; not sure why this would warrant a method (and the name of the method doesn't infer side effects (or that there would be in the future)). – Grant Thomas Dec 17 '12 at 15:12
  • OP is not talking about using a property versus a method, but about using the backing field directly versus using a property or a method. Personally I always use [auto properties](http://msdn.microsoft.com/en-us/library/bb384054.aspx), so there there isn't any backing field I can use. Not sure if it makes any difference. – comecme Dec 17 '12 at 15:27
  • @Grant Thomas relevance is what *comecme* said - the OP is asking about props vs private fields/fields (or method vs direct field access). Just throwing my 2 cents in about why you would use a prop or method over directly accessing the field – Charleh Dec 17 '12 at 15:50