About two years ago now I wrote part 1 and part 2of a MSDN article entitled 'Measure Early and Measure Often for Good Performance'.   In this article I mention some 'perf mantra' which is that

1. Every application deserves a 'perf plan' (which and be trivial if you have trivial performance needs)
2. That you need to measure.

Well, that second point (measuring), has never been as easy as you would like it to be.   However we do keep trying.

As part of this effort the CLR team has posted a useful tool, perfMonitor, on its codeplex site http://bcl.codeplex.com/.  

PerfMonitor is a application that can both collect performance data and create performance reports on managed (and unmanaged), applications.   It was designed to streamline the common case.   Lets assume you have an application called 'MyApp' and you wish to measure its end-to-end performance.    It is as simple as running the command

• PerfMonitor runAnalyze MyApp

If the app is interactive, you can interact with it and force it down the code paths you are interested in.   When the application completes, PerfMonitor will create a report.     Information in the report includes

• Total stats (total clock time consumed etc)
• CPU statistics, brown down by call stack.   For example below is the report for a tutorial example included with PerfMonitor,  If your app is interactive, it is likley to have 'spurts' of CPU activity, and to tool allows you to see these spurts in the timeline (and in fact focus on just that region if you so desire).   

• GC statistics of your application (How much memory are you consuming (See Memory Usage Auditing for .NET Applications for more on interpreting this data).
• Just in Time (JIT) compilation statistics.  This information is useful in determinging if you could improve the startup of your application by pre-compiling your appliction with the NGEN utility.

PerfMonitor tries to be helpful along the way, highlighting unusual performance data, and trying to put the data that it does in perspective.    The goal is that simple performance problems can be isolated in minutes, and harder problems are possible.     Because it is so easy to deploy and run PerfMonitor and look at the first level analysis, you really have to ask yourself 'why not'?  

Interested?

Another useful aspect of PerfMonitor is that it is REALLY easy to deploy.    It is a single EXE that requires no installation (just copy it to your machine and you can run it (It does require Vista OS or better).    To get it

1. Go to  perfMonitor site (or go to http://bcl.codeplex.comand search for PerfMonitor)
2. Click on the 'download page' link in the 'See aso' section
3. click on perfMonitor.bin.zip link
4. Read and accept the conditions of use, it will download the perfMonitor.bin.zip.  Click in the 'open' button to open the ZIP
5. If the browser brings up a security dialog, allow the opening of the zip.
6. Use explorer to bring up a directory to copy perfMonitor into (eg Documents).
7. Drag perfMonitor.exe to the target location. 

You can also simply double click on the perfMonitor.exe from either the ZIP file directly or wherever you copied perfMonitor to.   This will bring up the users guide, which will explain the features in detail. 

This is only the begining...

Over the next several weeks I will be posting more about perfMonitor and how to use it to help build high performance applications.     It is really just a (simple) front end on powerful performance monitoring technology built into windows called Event Tracing for Windows (ETW).   This is the same technology that the Windows team uses almost exclusively for its performance work, and is the basis for their VERY useful XPERF tool.    Because of this, PerfMonitor and XPERF can interoperate on the SAME wealth of performance data that the operating system can collect for you. 

There really are very few performance problems that the OS does not ALREADY capture the information needed to do an efficient analysis.   The key is having tools t display it and some basic knowledge that will guide you through the data.    This will be the subject of future posts....