This is my first real blog entry, so I would like to introduce myself. My name is Vance Morrison and I am currently a performance architect on the .NET Runtime Team. I am one of a handful of developers who have worked on the .NET runtime from its inception. I did most of my work in the Just in Time Compiler associated with the runtime (for example I was the primary contact for all IL opcode issues back in the time when we were actually adding opcodes). What is wonderful about working in the JIT compiler is that you are at what I consider the 'heart' of the runtime. Generally speaking, if it needs to be fast, the JIT needs to know about it. This gave me a lot of exposure to many of the conventions that are fundamental to the runtime's operation (What is the layout of an object, or array, how do virtual method calls happen? Where to security checks get put? How do you report GC pointers to the GC? When can a GC happen? ....) In reality the JIT has a whole is a just a performance optimization and so it is not so a big leap for me to change from optimizing small sequences of instructions to optimizing the runtime more holistically
In my new role, a bit part of what I need to do is to encourage best practices. This blog is one part of my new role. There has been a lot already written about .NET performance, much of which has been written by my predecessor Rico Mariani. This is all good stuff and I have spent a bunch of time reading about it. My focus is going to be a bit different. I want to focus on TOOLS. .
Part of the reason why performance is hard, is that either there are not good tools out there, or that there is not good guidance about how to use the tools well. For example NT has literally hundreds of performance counters. So many it is very difficult to understand which ones are actually good for what. PerfMon, the tool Microsoft ships to display this information has some useful information buried in its help, but most people give up long before they find it. It is also too terse to really be helpful. It is really just a monitoring tool for evaluating the overall health of your system. Once you determine your system is not healthy and have narrowed it to a particular process, you typically need other tools, and a debugger to drill further. Thus perfmon is useful, but it is not obvious how to use it well, and is only useful for one phase of a performance investigation. Seems like some guidance would be useful, so one of my blog entries will be on when I use perfmon, how I use it, and when I move on to other tools.
While I like to believe that I am an authority on some things (like how the .NET framework generates code), there are many more things where I can not offer authoritative guidance (like what half the performance counters collected by windows are good for). In short, I too, have a lot to learn. What I bring to the table is a passion for performance and a desire for finding and promoting the best tools for the job. Undoubtedly I will learn a lot for all of you along the way, and I look forward to it.