How Windows Supports Performance Monitoring

Although there are large number of third-party profiling and performance monitoring tools available, almost universally they will be implemented by one of two means: the data that they present to you will either be derived from performance counters, or from the profiling API.

• Performance counters can be thought of as components that continually record information about some aspect of the state of the computer or of the processes running on it. In most cases, the performance counters will store the data they obtain in memory-mapped files where it is available to other processes.

• The profiling API is a facility supplied by the CLR whereby an external unmanaged COM component can request to receive notifications of events that occur as a managed program is being JIT-compiled and executed. Typical events include method calls, class instantiations, and the throwing and catching of exceptions. The external component will normally analyze the information retrieved, and present it to the user via some user interface.

In general, utilities that use performance counters usually tend to get referred to as performance monitors, and those that hook up to the profiling API as profilers. Both types of application are important because they tend to supply different types of information. Performance counters excel at providing data about resource usage - how much memory an application is using, how much CPU time, how many exceptions are being thrown, how many threads have been created, and so on. Profilers, on the other hand, are able to use the notifications they receive to monitor the actual flow of execution in a program, and thereby gain more specific information about which code is being executed at what times. For example, a sophisticated profiler can tell you how many times a method has been called, and - very importantly - how much CPU time is being spent executing each method.

The fact that profilers are more intimately hooked into the actual execution flow of an application is reflected in their complexity. You'll typically find that performance monitors exist as simple standalone utility applications - the Task Manager is a very typical example of this. Profilers, on the other hand, are more usually complex applications that are typically designed to integrate into VS.NET, allowing you to obtain profiling information as you execute the code from VS.NET. In general, profilers are much larger, more sophisticated, applications than performance monitors, and are correspondingly far less likely to be available as freeware or shareware.

Developers who came to .NET from a background of Visual Studio 6 will remember that in those days, Visual Studio came with an integrated profiler. Sadly, that's one feature that was lost in the move to .NET. For the time being at least, it appears that Microsoft has decided to rely on third parties to supply .NET-compliant profilers.

Before we start to look in more detail at profiling and performance counting facilities, I want to point out one very important piece of advice.

Release and Debug Builds

Do be careful to do your profiling on release builds of your applications where possible. I know it sounds obvious, but accidentally profiling a debug build is a very easy mistake to make. Debug builds contain a lot of extra code which among other things may bloat memory, hang on to resources for longer, and will certainly change the relative amounts of time spent executing different methods. There may be occasions when you will have a specific reason to want to examine a debug build, but in most cases the information you get won't accurately reflect what the shipped version of your application is doing.

If you are responsible for compiling and profiling code then it's relatively simple to make sure you do a release build. If you have been handed an assembly for profiling which someone else has built, then you can check whether it's a release build by examining the assembly contents with ildasm.exe. Look for the assembly-level attribute, DebuggableAttribute. In a release build, this attribute will either not be present or, if present, will have been passed values of false (namely a zeroed block of memory) to its constructor. If this attribute is present in the assembly and has been passed non-zero data, then the chances are you have a debug build.