Vance Morrison's Weblog : Tools

Links to MSDN articles I have written on designing for performance

vancem — Wed, 22 Oct 2008 17:46:00 GMT

I just happen to notice that I don't have any links from my blog to some recient MSDN articles I wrote on performance. I want to quickly correct his with this posting.

There is actually a very nice summary page that MSDN created that gathers together all the articles I have written over time. The link is here (a web search of MSDN Vance Morrison will also turn it up).

The two articles I want to call your attention to however are these

CLR Inside Out: Measure Early and Often for Performance, Part 1

CLR Inside Out: Measure Early and Often for Performance, Part 2

These articles are about how most perf problems start very early in the design, and that there is no substitute for knowing how much things cost when doing your design.

There is a nice companion tool that I wrote callled 'MeasureIt' which you get download (free), that allows you to

Get a bunch of useful benchmarks on how much various .NET operations cost
Measure other stuff that you happen to be interested in easily (eg how fast is that collection class you are using?)

In fact, I intend I just recently used MeasureIt to measure how expensive the various levels of the CPU cache hierarchy are. (that is how much does a fetch from L1 cost? How much if you miss the L1 Cache but hit the L2 cache? How much more expensive is it when you miss both L1 and L2 and have to go to main memory?). If there is interest I can write a quick blog about that.

Measuring managed code quickly and easiliy: CodeTimers

vancem — Fri, 22 Sep 2006 06:16:00 GMT

My performance blog entries to date have been 'foundational'. In entries so far, I talk about how to use Visual Studio to look at the native code generated for the runtime. With this foundation, we can now start exploring what the native code for managed code looks like and what optimzations the runtime does on your behalf.

However before we do that, we need one more foundational piece. You really can't do performance work, without measuring, and so we need tools to help us measure. The simplest of these is the stopwatch. Thankfully Version 2.0 of the rutnime provides a nice, high resolution class that does this called System.Diagnostics.Stopwatch, which is ideal for measuring short intervals accurately.

As nice as System.Diagnositcs.Stopwatch is, I found myself wanting more. I was repeatingly typing code to start and stop the Stopwatch, subtracting the difference, subracting out the harness overhead, and doing statistics on the resulting numbers. This led me to write two classes to automate this, call CodeTimer, and MultiSampleCodeTimer. I have included the source for these in the Zip file below. Simply open it, copy the directory to your local drive, and open the .SLN file using visual studio. You can even compile the code without having Visual Studio. Simply run the buildIt.bat batch file The only prerequisite is that you need V2.0 of the .NET runtime installed (available from windows update, among other places).

The basic usage pattern for CodeTimer is

    CodeTimer timer = new CodeTimer();
    timer.Measure("Measurement Name", delegate {
       // Code that you want to measure
    });

Basically I am making use the 'anonymous delegate' feature of c# to allow the client to specify the code that he wants measured inline. One of the nice feature of anonymous delegates is that they 'capture' any local variables that are in scope. Thus you can write things like

   
    CodeTimer timer = new CodeTimer();
    string myString = "aString";
    string outString;
    timer.Measure("Measurement Name", delegate {
       outString = myString + myString;  // measuring concatination.  
    });

To measure the time it takes to concatinate two strings. What is actually going on 'under the hood' is that the C# compiler generates a class with two fields 'myString' and 'outString' (a field for every local variable referenced in the body of the delegate code). An instance of this class is created and initialized to the values of locals and this object is used to create a delegate to pass to 'Measure'. Thus the locals are 'captured' and passed to the code that 'Measure' will ultimately call.

This detail is imortant if you are measuring very small operations, because field access generates different code than local variable access. Thus in the example above, I am not just measuring string concatination, but also fetching an instance field (mystring) twice, and setting an instance field (outstring). Generally these fetches are small, and so they don't purturb the data much, but you should be aware of them.

When you are measuring very short times (like the case above), you are likely to wan to run the test in a loop. CodeTimer has built-in support for this. I can run the example above 1000 times in a loop by doing

   
    CodeTimer timer = new CodeTimer(1000);
    string myString = "aString";
    string outString;
    timer.Measure("Measurement Name", delegate {
       outString = myString + myString;  // measuring concatination.  
    });

Which tells 'timer' to run any measurment 1000 times. This is great for measuring micro-operations.

While 'CodeTimer' is great, I want still more. I don't want just one sample, but 10 or more, so I can take the average and standard deviation and understand how 'noisy' my data is. That is exactly what MulitSampleCodeTimer does. What is nice is that only the defintion of timer changes.

   
    MultiSampleCodeTimer timer = new MultiSampleCodeTimer(10, 1000);
    string myString = "aString";
    string outString;
    timer.Measure("Measurement Name", delegate {
       outString = myString + myString;  // measuring concatination.  
    });

Which asks that the code be run 1000 times per measurment and that 10 measurments be taken and used to compute min, max, mean, median and standard deviation. The results are then printed (we are reallly starting to add value).

I find I use MultiSampleCodeTimer alot. I use it in the'TypePerfMeasurement' project below to measure the speed of some reflection type constructs. More on that in my next blog entry.

SUMMARY:

In this blog entry, I have introduced to two classes 'CodeTimer' and 'MultiSampleCodeTimer' that can be used to meause the performance (time), of a wide variety of code. You are encouraged to open, copy and build the attached sample below (you don't need VS to do it just the .NET runtime), and try it for yourself. Measuring performance has never been easier.

Next time we will talk about the numbers that the TypePerfMeasurement experiment actually produce and talk about why the performance is the way it is.

HOW TO USE THE DEMO:

I want my blogs to be 'hands-on' which means that there should always be something you can do after reading to experiement with the concept I talked about (that is there is homework!). To make this easy I have attached a ZIP file that is a archive of a Visual Studio Solution for code to experiement with. Note that you do NOT Need Visual Studio to compile and run the demo, so don't let that stop you. To unpack this simply

Click on the ZIP file attachement at the bottom of the post. This will bring up a dialog asking if you wish to open the file.
Click on the 'Open' button. This will bring up an explore window displaying the contents of the ZIP file, which is a single directory. If you just want to look at files, you can browse the files directly from this window.
Open a target folder on your local computer. This can be anywhere, but if you have Visual Studio installed 'My Documents\Visual Studio 2005\Projects' is a good place
Drag the directory from the ZIP file window into the target folder. This copies the directory and all its contents to the local hard drive.
Once copied, you can close the ZIP window, and click into the target directory. There you will find a .SLN file, which you can double click on to bring up the solution in visual studio.
If you don't have Visual Studio, you can still build the solution, there is a one line batch file called 'buildIt.bat' file that does this (it simply turns around and calls MSBuild to do its work). You do need Version 2.0 of the .NET Framework installed. If you don't have it you can get it from www.windowsupdate.com (custom downloads), or here.
All the samples build and run and do something interesting 'out of the box', They are meant to be easy to understand, commented, samples so start looking around and experimenting (Hitting F10 to start stepping into the code is a good place to start).

Digging deeper into managed code with Visual Studio: Using SOS

vancem — Wed, 06 Sep 2006 02:55:00 GMT

I have let my blog laps for too long. I am back to blogging. I realized reciently that we have simply not written down many interesting facts about how the runtime actually works. I want to fix this. Coming up in future blogs I am going to be doing a bit of a 'architectural overview' which describe the differences between managed and unmanaged code, but before I do that I realized that I have not even finished a blog entry I started in March.

In my blog How to use Visual Studio to investigate code generation questions in managed code, I talk about the how to configure Visual Studio so that you can actually look at optimized code in the debugger (which sadly is not as trivial as you would like), and showed how to look at the disassembly of managed code. Unfortunately manage code is hard to read without a guide, and so in this blog I will show you some very useful tips for reading managed assembly code.

In this blog entry I will show you the instructions ACTUALLY need to get executed to do something as simple as assigning a string to field of a class. Note that I am assuming a familiarity with X86 assembly code. If you are the type who never wants to read assembly code, you should stop reading now, because most of this blog is a step-by-step explanation of it.

I have attached the file InspectingManageCode.zip, which contains a (trivial), project that I used for this example. You are STRONLY encouraged to open it (you can browse it the main file is Program.cs). Copy the files (simply drag the 'InspectingManagedCode directory inside the ZIP to a directory of your choosing), launch the InspecingManagedCode.sln file and run the example. While the project is already set to build and run optimized code, you will still need to turn off ‘just my code’ and turn on JIT optimization as described in my previous blog to follow along.

The code in the attached example is pretty trivial.

class Program

{

string myString;

private Program()

{

myString = "foo";

}

static void Main(string[] args)

{

Program p = new Program();

}

If you were to follow the instructions in the previous blog to see what code was generated for the body of ‘Main’ you would find the following code.

00000000 push esi

00000001 mov ecx,9181F4h

00000006 call FFCB1264

0000000b mov esi,eax

0000000d mov eax,dword ptr ds:[0227307Ch]

00000013 lea edx,[esi+4]

00000016 call 79222B78

0000001b pop esi

0000001c ret

At first glance this code has little similarity to the source code: the original source has a call the constructor ‘Program’ and the assembly code has two calls to strange hex addresses. There are also references to magical numbers like 9181F4H and 0227307CH. In this case the disassembly has not proven to be very valuable. What can we do? Sadly if we try to peer into these CALL instructions we cannot, the debugger comes back with the very unhelpful message ‘There is no code at the specified location’. Actually Visual Studio is LIEING to you. There really is code there, but it simply will not show you. I will show you techniques to get around this.

The key to unlocking mysteries of managed code, is a debug helper called SOS.DLL (it is a dll that is shipped with the runtime). The DLL is what is called a ‘debugger extension’. Basically it implements functionality that is useful in a debugger implementing functions that are useful for debugging code associated with it (in this case the runtime). Other bloggers have also commented on the use of this DLL (do a web search of SOS.DLL for more).

In Visual Studio, you load SOS.DLL by opening the immediate window (Ctrl-D I) and typing

.load SOS.dll

If you do this you may get the message

SOS not available while Managed only debugging. To load SOS, enable unmanaged debugging in your project properties.

This message is actually reasonably helpful. By stopping the debugger (Shift F5) going to Solution Explorer (Right hand pane), right clicking on the InspectingManagedCode project file, and selecting Properties, you will get the properties pane for the project. If you select the ‘Debug’ tab on the left side you will find 3 check boxes at the bottom, one of which is labeled ‘Enable unmanaged code debugging’ If you check this, you put the debugger into a mode where it can debug both mananged and unmanaged code, (which means you can then use SOS.DLL). I have already done this on the InspectingManagedCode project, but you will have to repeat this any time you need to use SOS. (Sadly the instructions for setting the debugger mode are different for C++). Note that running the debugger to debug both managed and unmanaged code will slow the debugger down a bit (it loads the symbols for all the unmanaged DLLS), so you probably only want do this on projects like this one where you want to use SOS.DLL.

Now you should be able to set a breakpoint in Main(), run the program (F5), and go to the immediate window (CTRL-D I) and type

.load SOS.dll

And get the message

extension C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded.

If you are curious the SOS.DLL has reasonably good help, if you type the command

!Help

It will give you a list of commands, and you can get help on individual commands by specifying the name eg.

!Help u

It will give you help on the ‘u’ (unassembled) command. All SOS commands need to be prefixed by a ! character so that the Visual Studio Debugger knows that it is an SOS command and not an immediate value to be interpreted (the normal meaning of text typed in the immediate window).

The unassemble SOS command is the command we are interested in. It will disassemble a managed routine, but do a much better job than Visual Studio presently does. Unfortunately, we need the address of the routine we want disassemble, and Visual Studio goes to some length to hide this information. If you look at the disassembly for the code (CTRL-ALT-D), you will see that the address of the routine is never given, only the offset from the beginning of the method.

The way around this is to use the ‘Registers window’ (Ctrl-D R). I happen to like to put this window just above the immediate window and shrink it so that only the two lines that actually show values are showing. One of the registers is ‘EIP’ which stands for Extended Instruction Pointer’. It is the address of the current instruction pointer. In my particular invokaction EIP has the value of 00DE0071, so I can do the command

!u 00DE0071

Which will disassemble the ENTIRE routine that the address 00DE0071 lives in. I like to right click in the immediate window and select ‘Clear All’ before I do this so the only thing in that window is the disassembly. On my machine I get the result

Normal JIT generated code

Program.Main(System.String[])

Begin 00de0070, size 1d

00DE0070 56 push esi

>>> 00DE0071 B904309100 mov ecx,913004h

00DE0076 E8A11FB2FF call 0090201C (JitHelp: CORINFO_HELP_NEWSFAST)

00DE007B 8BF0 mov esi,eax

00DE007D 8B053C302B02 mov eax,dword ptr ds:[022B303Ch]

00DE0083 8D5604 lea edx,[esi+4]

00DE0086 E8A5380979 call 79E73930

00DE008B 5E pop esi

00DE008C C3 ret

It is not unlike the version the Visual Studio produced, but there are differences

1. You will note that the ‘call instruction is annoted with ‘JitHelp: CORINFO_HELP_NEWFAST’, which makes it at least a bit clearer that this helper is used to create a New object (and is the fast version, we have many variations).

2. It printed the whole routine that 00DE0071 lives in and prints a >>> on the instruction corresponding to the 00DE0071 address.

3. While it did not print the name for the ‘call 79E73930’, notice that the HEX value is different than the value in the Visual Studio Disassembly (79222B78). The value in the VS disassembly is simply WRONG (it is bug no one bothered to fix).

So let’s take a look at the first two instructions.

00DE0071 B904309100 mov ecx,913004h

00DE0076 E8A11FB2FF call 0090201C (JitHelp: CORINFO_HELP_NEWSFAST)

I mentioned that this helper call creates a new object from the GC heap. To do so it needs to know that type of the object to be created. This is what the magic number 913004 does. Internally in the runtime types are described by a structure called a MethodTable, and 913004 is the address of the MethodTable to create. We can find out what type 913004 corresponds to by using the !DumpMT (dump Method Table) SOS command.

!DumpMT 913004h

Produces the output

EClass: 00911254

Module: 00912c14

Name: Program

mdToken: 02000002 (C:\Documents and Settings\vancem\My Documents\Visual Studio 2005\Projects\InspectingManagedCode\bin\Release\InspectingManagedCode.exe)

BaseSize: 0xc

ComponentSize: 0x0

Number of IFaces in IFaceMap: 0

Slots in VTable: 6

The only output of this that is interesting at this point is the ‘Name’ field, which as you can see, indicates that 913004 cooresponds to the ‘Program’ type. Thus these first two instructions create a program object. This program object comes back from the helper with all its fields zeroed, so the next instructions in the program are the body of the constructor (the Program() constructor has been inlined into the body of Main().

The next instructions

00DE007B 8BF0 mov esi,eax

00DE007D 8B053C302B02 mov eax,dword ptr ds:[022B303Ch]

00DE0083 8D5604 lea edx,[esi+4]

00DE0086 E8A5380979 call 79E73930

Basically implement the statement ‘myString = "foo"’ The helper returns a pointer into the uninitialized object in the EAX register. The mov saves this into the ESI register. EAX is then loaded with what is at the address 022B303Ch. This happens to be the string “foo” (more on how it go there in a later blog). You can confirm this by going to the disassembly code, setting a breakpoing right after the eax,dword ptr ds:[022B303Ch] instruction and looking at the value of the EAX register in the ‘registers’ window. In my example it happens to be the value 012B1D44. You can then use the command

!DumpObj 012B1D44

Which will dump the managed object at this address. This will print .

DumpObj 012B1D44

Name: System.String

MethodTable: 790fa3e0

EEClass: 790fa340

Size: 24(0x18) bytes

(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

String: foo

Fields:

MT Field Offset Type VT Attr Value Name

790fed1c 4000096 4 System.Int32 0 instance 4 m_arrayLength

790fed1c 4000097 8 System.Int32 0 instance 3 m_stringLength

790fbefc 4000098 c System.Char 0 instance 66 m_firstChar

790fa3e0 4000099 10 System.String 0 shared static Empty

>> Domain:Value 0014c550:790d6584 <<

79124670 400009a 14 System.Char[] 0 shared static WhitespaceChars

>> Domain:Value 0014c550:012b186c << Basically

Again, most of the output is uninteresting at this point, except the Name field (which says its a string), and the ‘String’ field (which shows the string value is ‘foo’). So we have confirmed that this instruction loads up the address of the ‘foo’ string into the EAX register. What is left is

00DE0083 8D5604 lea edx,[esi+4]

00DE0086 E8A5380979 call 79E73930

The first instruction ‘LEA’ may not be familiar to you. It is Load Effective Address (LEA). Basically it works just like a MOV instruction, but instead of moving what was AT the memory specified, it loads the ADDRESS of the memory. Another way of looking at this is to imagine a MOV instruction with the [] dropped (which represent memory fetching). Thus

00DE0083 8D5604 lea edx,[esi+4]

Can be thought of as

00DE0083 8D5604 mov edx, esi+4

That is it adds 4 to ESI and places it in EDX. Now remember ESI points at our newly created ‘Program’ object. We could find out all the fields of this object by dumping it, In my debugger ESI has the value of 012B1D5C so I can do

!DumpObj 012B1D5C

And get

Name: Program

MethodTable: 00913004

EEClass: 00911254

Size: 12(0xc) bytes

(C:\Documents and Settings\vancem\My Documents\Visual Studio 2005\Projects\InspectingManagedCode\bin\Release\InspectingManagedCode.exe)

Fields:

MT Field Offset Type VT Attr Value Name

790fa3e0 4000001 4 System.String 0 instance 00000000 myString

Which tells us that ESI points at a ‘Program’ object and that the total size of the object is 12 (more on that in a later blog), and that at offset 4 there is a field calls ‘myString’ of type System.String that currently has the value of 0 (null).

So now we can make a pretty good guess that the LEA instruction is setting EDX to the address of the ‘myString’ field of the program object. EAX has been set to the ‘Foo’ String, and next comes the mysterious

00DE0086 E8A5380979 call 79E73930

Ideally SOS would have annotated this helper. It is what we call a ‘WriteBarrier’. More on exactly what a write barrier is later, but for now the important thing to know is that ALL updates to OBJECT REFERENCES that live in the GC heap need to be done by calling a write barrier helper. Since the Program object lives in the heap, and we are updating a object reference pointer inside it we need to use the write barrier.

The runtime actually has many write barriers. All the write barriers have an unusual calling convention. They all take the address to be updated in the EDX register. Then depending on the write barrier, they take the value to update in some other register (this particular write barrier is the most commonly used, and takes its argument in the EAX register). Logically all the write barrier does is do (*EDX = EAX) (that is update what EDX points at to be the value in EAX).

That is about it for this example The only instructions we did not cover are the PUSH ESI, and POP ESI at the beginning and end of the routine. As anyone who deals with assembly code this is simply saving and restoring ESI since we used it in the routine itself.

To recap here are the instructions that actually got executed in the ‘Main’ program and what they do.

push        esi                                        // save ESI
mov         ecx,913004h                        // ECX = MethodTable(Program)
call        0090201C                              // EAX = New Object (Program)
mov         esi,eax                                 // ESI = this (new object)
mov         eax,dword ptr ds:[022B303Ch]      // EAX = “foo”
lea         edx,[esi+4]                             // EDX = &this.myString
call        79E73930                              // this.myString = EAX (“foo”)
pop         esi                                         // restore ESI
ret                                                        // return.

We just understood very deaply EXACTLY what happens when a particular piece of managed code executes. Hopefully that wasn’t so bad. Next time we will dig a bit into this WriteBarrier is and exactly what it does (how expensive is it?). We will also dig into exactly what went on inside the ‘New’ helper. In later blogs I will go into how exactly other run time features get converted to native code.

I hope you are enjoying this peek under the hood of the .NET Runtime.

How to use Visual Studio to investigate code generation questions in managed code.

vancem — Tue, 21 Feb 2006 01:35:00 GMT

Introduction: What does ‘foreach’ actually do?

It is not uncommon for a new group to want to use manage code to pepper the CLR team with performance questions. They want to know how expensive ‘foreach’ is, or whether certain methods get inlined or a variety of other questions about the code quality of.

Sometimes, people look at the IL in attempt to answer questions about the code quality of managed code, however this approach is misguided. The JIT compiler transforms the code tremendously going from IL to native, and thus for most performance questions the quality of the IL does not correlate strongly with the ultimate performance of the code. For codegen performance questions, what matters most is the quality of the JIT compiler.

Often internal partners will simply ask us how questions about what code gets generated for a particular construct, and every time they do this I think ‘Why should I have to do this? Run it under a debugger and see for yourself!’ This blog is the step-by-step instructions for doing just this in Visual Studio.

Conceptually, the process of determining what Native code is generated by a construct is very straightforward

Find or generate code that has the construct you wish to understand
Compile the code with optimizations turned on
Run it under a debugger, stepping to the code interesting code an view it in the disassembly window.

Unfortunately, while all of these are possible to do in Visual Studio, the defaults work against you and you have to know how to change them.

To make things concrete, I will go through the steps for an example. I happen to interested in looking at the the overhead of a foreach() for List<int>.

[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]

static void F(int arg) {}

static void ForEachTest(List<int> list) {

foreach (int elem in list) {

F(elem);

}

Compiling the code with optimizations:

This part is almost straightforward in Visual Studio. You would have liked it to be the case that simply compiling the ‘Debug’ to ‘Release’ in the Solution Configuration window at the top-center of the VS IDE would be sufficient. Unfortunately this is simply not true for C# projects (I have not checked for VB or C++ projects).

The issue is that by default release builds do NOT build the program data base (PDB) files that hold the line number and local variable information. This makes it impossible for the debugger to correlate the assembly code back to line numbers. This makes it much more difficult to read the assembly code for large methods. To fix this going to the properties for the project (right click on the project in the Solution Explorer), select the ‘Build’ tab and click the ‘Advanced’ button at the bottom. In the dialog box that comes up there will be a line ‘Debug Info’. It should be set to ‘pdb-only’. This tells the compiler to compile with optimizations, however also create a pdb file.

With that done, make certain your Solution Configuration window says ‘Release’ and compile your solution (F6).

Running optimized managed code:

Sadly, Visual Studio makes debugging optimized code harder than you would like. First, by default, if you launch a managed program under Visual Studio, it will force the JIT compiler to created non-optimized native code. This improved debuggability, but makes it impossible to see that code that actually runs when the app is not run under Visual Studio. The other problem is that Visual Studio has a feature called ‘Just My Code’ in which the debugger will not step into code that it does not believe is being developed. In particular any optimized code is not considered ‘My Code’ and is skipped. Again this makes it impossible to actually stop and see the optimized code.

To fix both of these problems

1) Go to Tools -> Options -> Debugging -> General

2) Make certain that box labeled ‘Suppress JIT optimization on module load’ is UNCHECKED.

3) Also make certain the box labled ‘Enable Just My Code’ is also UNCHECKED.

Note that these are global settings (the affect all solutions), however, I have found I don’t miss either of these ‘features’ (Code compiled ‘Debug’ is still not optimized by the JIT so you still get good debugging there).

Once you have disabled this ‘features’, set a breakpoint at an interesting spot (F9) and run the program (F5).

Examining the optimized code:

Once your breakpoint is hit, it is a simple matter of switching to the disassembly window (Ctrl D CtrlD, or Debug -> Windows -> Disassembly) to look at your code.

You should not see and ‘nop’ instructions in the code. If you do this means you are looking at a ‘Debug’ build of your code. It is not a bad idea to run a simple test by creating a function that returns a constant integer and confirm that it gets inlined in the resulting assembly code. This confirms that all the preceding steps were successful.

You will notice that the assembly code does not have symbolic names for the call targets. Often this is not a hardship, because you can deduce it from the corresponding source line associated with the assembly code. If for things like ‘foreach’ or other constructs where the IL compiler is doing significant work, it is a hardship not to know what the symbolic name of the target is. In the case of my example above the interesting code is

00000077 mov ecx,dword ptr [ebp-24h]

F(elem);

0000007a call dword ptr ds:[00913028h]

foreach (int elem in list) {

00000080 lea ecx,[ebp-30h]

00000083 call 7878BFF4

00000088 test eax,eax

0000008a jne 00000077

So we are pretty sure that we know that dword ptr ds:[00913028h] is really our F() method, however we don’t know what this 7878BFF4 that we call a bit further down. You also might not know what instructions like ‘lea’ do, or how the ‘elem’ parameter is passed to our ‘F’ method.

Luckily all of these issues (and others) will be the topic of my next blog entry.

Recap:

In this blog entry I have given step-by-step instructions for using Visual Studio to look at optimized managed code. Hopefully you will agree that is really is not that bad at all, and it now gives you the tool to answer a whole host of questions such as

1) Is a particular method inlined or not?

2) Does the JIT perform optimization X?

Note that the example above was for X86, but the technique above works just as well for X64. Note that the X64 JIT compiler and the X86 JIT compiler are completely different, so you if you care about performance on both platforms, you will need to repeat your experiment on both platforms.