Properties slower than fields

Question

It seems that every post I have come across comes to the same consensus: properties that merely return a field are inlined by JIT and have nearly identical performance to fields.

However, this doesn't seem to be the case with my current scenario. My program does intensive calculations that access many properties that are simply auto-getters and private setters. In this particular case, however, I am just copying an object.

Profiling the code in release mode with optimizations enabled resulted in many calls to the get functions of the property. The calls to Copy() total up to ~5.6ms.

However, when the properties are converted into fields, the function runs 6x faster than it did with properties:

Comparing equality of two properties seems to incur even more of a performance hit compared to using fields. Here's a benchmark of a class's IEquatable implementation, using the same code but swapping properties with fields.

If JIT is supposed to optimize properties by inlining them, why is this occuring? I would like to keep properties, as the access control aspect of them is very convenient, but if they are this much slower I will stick to fields.

EDIT: It seems like some (but not all) cases affected by this problem are using properties declared in interfaces. No other polymorphism is being used in these cases, but removing the interface brings the performance variance into expected levels in these cases.

EDIT 2: As stated in the previous edit, it seems that a part of the problem was due to Interface virtual calls. After more investigation, it seems that running a benchmark in the CLR properly inlines properties, but JetBrains dotTrace does not, even with "Enable inline" checked.

Answer 1

Unfortunately the is not much more you can do except try to help the JITTER out by using

[MethodImpl(MethodImplOptions.AggressiveInlining)]

AggressiveInlining The method should be inlined if possible.

Now technically this can only be used on a method or construtor, however you can seemingly test it on the getters and setters them selves. ie it compiles (i haven't tested this though)

public int someType
{
   [MethodImplAttribute(MethodImplOptions.AggressiveInlining)]
   get;
   [MethodImplAttribute(MethodImplOptions.AggressiveInlining)]
   set;
}

Note : in-lining is a blackbox of wonderment, the jitter may feel like it or not, even the attribute is only a suggestion. also note that the bitness may also affect what it inlines.

Lastly, i think you are going about this the right way, you should just use a bechmarker or profiler, and micro-optimize accordingly,