views:

65

answers:

3

For one reason or another, I sometimes find it useful or just interesting to look at the optimised compiler output for a function.

For unmanaged C/C++ code, my favourite way to do this has been to compile in Release mode, stick a breakpoint in the function of interest, run, and view the disassembly in Visual Studio when it hits the breakpoint.

I recently tried this with a C# project and discovered that that technique doesn't work. Even in Release mode, the disassembly I see is obviously not optimised. I found and disabled (in Visual Studio 2010) the "Debug ... Options and Settings ... Debugging ... General ... Suppress JIT optimization on module load" option, which presumeably gets me closer to what I want, only now it warns me when I try to run it, and I then can't get it to stop on a breakpoint so that I can see the disassembly.

So, if I want to see the disassembled, optimised output of the CLR (4.0) jitter for a function, what's the best way to go about that? To be clear, I'd like to see the x86 (or preferably x86_64) disassembly, not just the IL disassembly (which you can see in Reflector).

A: 

You could try inspecting an NGEN'd assembly, but that would be quite hard as no metadata is present. But it could work :)

leppie
+2  A: 

Of course, after half a day of searching for the answer on this one, I find the answer myself 5 minutes after I ask on SO.

I was close; the only missing step from what I had in the question was that "Enable Just My Code" must also be unchecked in the options.

The full guide is available here: http://blogs.msdn.com/b/vancem/archive/2006/02/20/535807.aspx

Wesley Hill
Dont you love (and hate) it when that happens? :)
leppie
@leppie: Pretty much. It was a case of needing to know the solution to know what phrase to search for to find the solution...
Wesley Hill
+1  A: 

I believe the JIT knows when you're running under a debugger, and generates more "debugger-friendly" x86 code, which would explain why the x86 code you saw was unoptimized.

You might try running the app standalone, executing the code you're interested in at least once (so it JITs without the debugger attached), then attach the debugger to the process and set your breakpoint.

Joe White