1. Computing

Performance Counters

A Window Into Your Computer.

By

Updated August 20, 2011

Here's the problem: Your application isn't performing and you need to know why. Just looking at the code hasn't helped. You need hard data. You have some choices:

  • Use a StopWatch control to time various parts of your program.
  • Use WMI (Windows Management Instrumentation) to measure exactly what various parts of Windows is doing when your program runs.
  • Use PerformanceCounter objects to tell you what the program is doing.

If you have the Premium or Ultimate edition of Visual Studio 2010, there is also an "Analyze" menu that you can use. This menu offers a Profiling Wizard to gather Sampling data in a Profiling session. Ultimate will even add the counter data to a graph for you. Unfortunately, the Express products don't support performance counters. This article doesn't cover these tools. Many Microsoft pages fail to make it clear that you have to have higher priced versions to use some of the tools. (Microsoft has to hold something back or no one would buy the high-priced spread.)

These choices are a little like the story of Goldilocks and the Three Bears.

StopWatch is easy to code, but it's probably just not powerful enough to tell you much. You can spend a lot of time changing the location of StopWatch code and still not find anything. Even if you do, it might not really tell you what you need to know because it might not give you a clue about "why" the code isn't performing.

WMI is powerful, but it can be a 'bear' to write the code. I wrote a three part series on using VBScript and WMI several years ago that still looks pretty good considering its age that could help you use WMI to solve your problem.

  • Introducing VBScript - An overview of VBScript and WSH using a coding example that manages your Windows desktop.
  • Real World Scripting - Builds on the foundation in Part 1 with a scripting example that demonstrates how to dig into WMI scripting.
  • Scriptomatic - A utility to automate the creation of WMI VBScript programs.

For most people, choice number three, using performance counter objects, is "just right". You can find Microsoft pages that say, "Performance Counters is designed for use by C and C++ developers." But they're really not that hard to code and this article is dedicated to proving that. They can zero in on huge variety of performance parameters. You can even build your own performance counters that are based on the ones supplied.

WMI can still be a better choice for many people, in part because performance counters can be accessed as well as other data. But that just brings us back to the topic of this article: how to use performance counters.

The place to start in using performance counters is to check out the list of available predefined counters. It's a big list. Microsoft's documentation doesn't even attempt to tell you. Here's what they say about it, "The predefined counters are too numerous to mention and are product-specific." The best way to see what they are is to boot up Visual Studio and browse through the counters available on your machine.

Locate Server Explorer and select the Servers item. (You might have to connect to your local machine as a "server". Mine is named "Mukuntuweap" in the illustrations that follow.)

--------
Click Here to display the illustration
--------

You can now browse through a pretty impressive list of predefined counters.

--------
Click Here to display the illustration
--------

Figuring out how to code them is a lot easier. The way to understand them is to think of them as resources with multiple part names. Microsoft points out that they're a lot like referencing a file using a name. You have to include the drive, directory, subdirectory or subdirectories, and then a file name. With performance counters, you usually need a CategoryName, CounterName, and, optionally, the InstanceName or MachineName properties.

The code below shows a complete example that reads Bytes in Loader Heap, one of the values in one of the counters in the illustration above. Note that this list is preconfigured to include the heap size of the vshost that the example program is running in, PerformanceCounterExample.vshost.

--------
Click Here to display the illustration
--------

Figuring out just what all these counters really mean can be the most difficult part of the job. But I was surprised to learn that the CounterHelp property of the each counter is one of the best sources of documentation. For example, here's the CounterHelp property of the % Privileged Time counter:

"% Privileged Time is the percentage of elapsed time that the process threads spent executing code in privileged mode. When a Windows system service in called, the service will often run in privileged mode to gain access to system-private data. Such data is protected from access by threads executing in user mode. Calls to the system can be explicit or implicit, such as page faults or interrupts. Unlike some early operating systems, Windows uses process boundaries for subsystem protection in addition to the traditional protection of user and privileged modes. Some work done by Windows on behalf of the application might appear in other subsystem processes in addition to the privileged time in the process."

You can learn a lot about Windows just browsing through these counter descriptions!

On the next page, we work with specific counters in code!

©2014 About.com. All rights reserved.