tags:

views:

199

answers:

2

Does the .NET CLR runtime know how to optimize/inline simple property getters at runtime? For example:

property int Length { get; set; }

Will this be executing the "Length__get" function (building a stack for it, jumping to execute the code, etc) once it is JIT'd at runtime? Or is the jitter smart, and knows that this can just be rewritten as class field access?

+9  A: 

Yes, the CLR will inline that in "normal" cases. There are some situations in which inlining doesn't take place, however - including anything derived from MarshalByRefObject (because it could be a runtime proxy).

The rules for what gets inlined depend on the exact CLR you're using - x64 vs x86, version etc. Trivial properties are about as likely to be inlined as you'll get though :)

(For some reason I've seen a trivial property be slower than a field access for doubles in the past... there may be some restrictions around values larger than the native word size.)

Jon Skeet
@Jon, what did you mean by "values larger than the native word size"?
Joan Venge
I mean things like a long or double (each of which is 64 bits) on a 32 bit processor.
Jon Skeet
Thanks Jon. .
Joan Venge
+3  A: 

In .Net 2.0, methods (including property getters/setters) would be inlined if they had fewer than 32 bytes.

The .Net 3.5 JIT'r is a bit more intelligent, so it depends. It certianly could inline it.

For some discussion of this, see To Inline or not to Inline: That is the question.

Stewart
Good link. Vance Morrison talks in detail about what does and does not get inlined in .NET 3.5.
Robert Harvey
Interesting point about more code (generated via inline) executing slower because of L1 cache misses.
Armentage