Can C# properties make the program run slower?

Question

I'm concerned of people always using getter-setter pattern:

    public int MyVariable { get; private set; }

    public void SomeFunction(){
        MyVariable = 10;
    }

Which as far as I understand compiles to something like:

    private int myVariable;

    public int GetMyVariable(){
        return myVariable;
    }

    private void SetMyVariable(int value){
        myVariable = value;
    }

    public void SomeFunction()
    {
        SetMyVariable(10);
    }

Doesn't it impact the program's performance if used frequently? Isn't it better to do like that:

    private int myVariable;
    public int MyVariable { get {return myVariable; } }

    public void SomeFunction(){
        myVariable = 10;
    }

I highly doubt this is the area where you will have your primary performance problem in a real-world application. — mellamokb, Jan 22 '13 at 00:44
Whhoooaaa... is this my old manager? He told our team that if he ever saw any of those get/set things in our code, he would fire us. True Story. — Metro Smurf, Jan 22 '13 at 00:59
@MetroSmurf Those types of managers just make good developers leave ;) — Reed Copsey, Jan 22 '13 at 01:02
What the C# compiler does with the property doesn't matter. The code that runs on your machine is vastly different. Check this answer: http://stackoverflow.com/a/4045073/17034 — Hans Passant, Jan 22 '13 at 01:03
@MetroSmurf Then he doesn't know what he is talking about. Check my link, it backs my answer. — FrostyFire, Jan 22 '13 at 01:03

score 5 · Accepted Answer · answered Jan 22 '13 at 00:54

First off, this type of optimization is typically counter productive - trying to optimize out single method calls is something that will typically have no impact in any real world, measured performance. You're likely better off focusing your efforts on optimizing the algorithms you use at a higher level, and not micro-optimizing the language features used.

Doesn't it impact the program's performance if used frequently? Isn't it better to do like that:

No. This will be effectively the same once compiled.

In addition, in a release build, the JIT compiler will typically completely optimize away the get and set methods, inlining them completely. This will effectively make it perform exactly like using a public field, and have the same performance as a direct member access.

Exactly. Using `get` and `set` is the __best__ policy, even if they are just mindless `return xxx` and `this.xxx = value` statements. The point is that if you ever need to change the behavior/validation of these settings, you can do it in __one__ place (in the `get/set`) instead of every place you access it. Can you imagine for some property used in 100+ locations needing to be "checked for bounds" without doing that at the property level? Ugh. — Erik, Jan 22 '13 at 01:09

FrostyFire · Answer 2 · 2013-01-22T00:52:45.353

Its the same thing when it's compiled.

For proof you can check out this link. Here is an excerpt from it:

Notice how the get and set accessors in Listing 10-5 do not have implementations. In an auto-implemented property, the C# compiler creates the backing store field behind the scenes, giving the same logic that exists with traditional properties, but saving you from having to use all of the syntax of the traditional property.

score 1 · Answer 3 · answered Jan 21 '20 at 13:24

It depends on the compiler. Yes, it may impact the performance. For example, if you are developing a game with Unity Engine properties will be likely not converted to fields automatically, you can inspect produced IL2CPP code and find their C++ wrappers. So, you can win a little if you will use fields instead in render and physics loops. If you have huge amount of such properties access you probably will not find any of them alone in profiler so it will be hard to optimise in the future if all your huge codebase has a lot of properties in critical places because their impact will be distributed evenly. So, I prefer to make things more optimal in critical places right in the development time not delaying them to profiling times. But it is OK to have properties in less critical places.

Can C# properties make the program run slower?

3 Answers3