Field vs Property. Optimisation of performance

The only explanation could be is that the CLR does additional optimisation (correrct me if I am wrong here).

Yes, it is called inlining. It is done in the compiler (machine code level - i.e. JIT). As the getter/setter are trivial (i.e. very simple code) the method calls are destroyed and the getter/setter written in the surrounding code.

This does not happen in debug mode in order to support debugging (i.e. the ability to set a breakpoint in a getter or setter).

In visual studio there is no way to do that in the debugger. Compile release, run without attached debugger and you will get the full optimization.

I do not believe that in real application where those properties being used in much more sophisticated way they will be optimised in the same way.

The world is full of illusions that are wrong. They will be optimized as they are still trivial (i.e. simple code, so they are inlined).

Have a look at the Properties vs Fields – Why Does it Matter? (Jonathan Aneja) blog article from one of the VB team members on MSDN. He outlines the property versus fields argument and also explains trivial properties as follows:

One argument I’ve heard for using fields over properties is that “fields are faster”, but for trivial properties that’s actually not true, as the CLR’s Just-In-Time (JIT) compiler will inline the property access and generate code that’s as efficient as accessing a field directly.

The JIT will inline any method (not just a getter) that its internal metrics determine will be faster inlined. Given that a standard property is return _Property; it will be inlined in every case.

The reason you are seeing different behavior is that in Debug mode with a debugger attached, the JIT is significantly handicapped, to ensure that any stack locations match what you would expect from the code.

You are also forgetting the number one rule of performance, testing beats thinking. For instance even though quick sort is asymptotically faster than insertion sort, insertion sort is actually faster for extremely small inputs.

As others have already mentioned, the getters are inlined.

If you want to avoid inlining, you have to

• replace the automatic properties with manual ones:

  class A 
  {
      private double p;
      public double P
      {
          get { return p; }
          set { p = value; }
      }
  } 
  

• and tell the compiler not to inline the getter (or both, if you feel like it):

          [MethodImpl(MethodImplOptions.NoInlining)]
          get { return p; }
  

Note that the first change does not make a difference in performance, whereas the second change shows a clear method call overhead:

Manual properties:

auto getter. 519005. 10000971,0237547.
      field. 514235. 20001942,0475098.

No inlining of the getter:

auto getter. 785997. 10000476,0385552.
      field. 531552. 20000952,077111.