Can I check if the C# compiler inlined a method call?

Question

I'm writing an XNA game where I do per-pixel collision checks. The loop which checks this does so by shifting an int and bitwise ORing and is generally difficult to read and understand.

I would like to add private methods such as private bool IsTransparent(int pixelColorValue) to make the loop more readable, but I don't want the overhead of method calls since this is very performance sensitive code.

Is there a way to force the compiler to inline this call or will I do I just hope that the compiler will do this optimization?

If there isn't a way to force this, is there a way to check if the method was inlined, short of reading the disassembly? Will the method show up in reflection if it was inlined and no other callers exist?

Edit: I can't force it, so can I detect it?

Answer 1

Nope, you can't.

Basically, you can't do that in most modern C++ compilers either. inline is just an offer to the compiler. It's free to take it or not.

The C# compiler does not do any special inlining at the IL level. JIT optimizer is the one that will do it.

Answer 2

"You can check System.Reflection.MethodBase.GetCurrentMethod().Name. If the method is inlined, it will return the name of the caller instead."

--Joel Coehoorn

Answer 3

No you can't. Even more, the one who decides on inlining isn't VS compiler that takes you code and converts it into IL, but JIT compiler that takes IL and converts it to machine code. This is because only the JIT compiler knows enough about the processor architecture to decide if putting a method inline is appropriate as it’s a tradeoff between instruction pipelining and cache size.

So even looking in .NET Reflector will not help you.

Answer 4

You can detect it at runtime with the aforementioned GetCurrentMethod call. But, that'd seem to be a bit of a waste[1]. The easiest thing to do would to just ILDASM the MSIL and check there.

Note that this is specifically for the compiler inlining the call, and is covered in the various Reflection docs on MSDN.

If the method that calls the GetCallingAssembly method is expanded inline by the compiler (that is, if the compiler inserts the function body into the emitted Microsoft intermediate language (MSIL), rather than emitting a function call), then the assembly returned by the GetCallingAssembly method is the assembly containing the inline code. This might be different from the assembly that contains the original method. To ensure that a method that calls the GetCallingAssembly method is not inlined by the compiler, you can apply the MethodImplAttribute attribute with MethodImplOptions.NoInlining.

However, the JITter is also free to inline calls - but I think a disassembler would be the only way to verify what is and isn't done at that level.

Edit: Just to clear up some confusion in this thread, csc.exe will inline MSIL calls - though the JITter will (probably) be more aggressive in it.

[1] And, by waste - I mean that (a) that it defeats the purpose of the inlining (better performance) because of the Reflection lookup. And (b), it'd probably change the inlining behavior so that it's no longer inlined anyway. And, before you think you can just turn it on Debug builds with an Assert or something - realize that it will not be inlined during Debug, but may be in Release.

Answer 5

why not use unsafe code (inline c as its known) and make use of c/c++ style pointers, this is safe from the GC (ie not affected by collection) but comes with its own security implications (cant use for internet zone apps) but is excellent for the kind of thing it appears you are trying to achieve especially with performance and even more so with arrays and bitwise operations?

to summarise, you want performance for a small part of your app? use unsafe code and make use of pointers etc seems the best option to me

EDIT: a bit of a starter ? http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

Answer 6

Yes you can detect it. If your method is "private static" and small there is a chance compiler can inline it.

In order to detect it uncheck "Just my code" and "Disable JIT optimizations" in Visual Studio (Options -> Debugging). Build your code in "Release" mode and put a breakpoint where you call the function. Then look at JIT disassembly.

Answer 7

Is there a way to force the compiler to inline this call or will I do I just hope that the compiler will do this optimization?

If it is cheaper to inline the function, it will. So don't worry about it unless your profiler says that it actually is a problem.

For more information

JIT Enhancements in .NET 3.5 SP1

Answer 8

Be aware that the XBox works different.

A google turned up this:

"The inline method which mitigates the overhead of a call of a method. JIT forms into an inline what fulfills the following conditions.

• The IL code size is 16 bytes or less.
• The branch command is not used (if sentence etc.).
• The local variable is not used.
• Exception handling has not been carried out (try, catch, etc.).
• float is not used as the argument or return value of a method (probably by the Xbox 360, not applied).
• When two or more arguments are in a method, it uses for the turn declared.

However, a virtual function is not formed into an inline."

http://xnafever.blogspot.com/2008/07/inline-method-by-xna-on-xbox360.html

I have no idea if he is correct. Anyone?

Answer 9

The only way to check this is to get or write a profiler, and hook into the JIT events, you must also make sure Inlining is not turned off as it is by default when profiling.