What's the working paradigm of Windows Performance Counter?

Question

I have just finished reading this article about how to create a performance counter and update the counter's value. But I am a little confused about the working paradigm of the Windows Performance Counter. Suppose there're 2 programs A and B, and A want to know B's performance through some performance counters. Which of the following scenarios is correct?

• B create/register some performance counters into the Windows and B is responsible for updating the counters' value. A could be the system perfmon.exe. A is not actively probing B's execution status. A just check the registerd counters and get the value which is supplied and updated by B. Even there is no A, the B still always updates its registered performance counters. But isn't this some kind of burden to B's performance?

• A actively probes B's execution status and figure out the performance counter value. In this paradigm, B doesn't have any extra burten.

  In short, who is responsible for create and update the Performance Counters? The object program whose performance is being measured? Or the subject program who is measuring the object program's performance? For program A, is it a probing scenario? or just a reading scenario?

Many thanks.

Answer 1

Performance Counters could be an interesting question, but what is your overall goal? Are you interested in finding out how to make programs run faster?

If not, please disregard this answer.

If so, then there is a point of view saying that performance counters exist for the purpose of counting things, things that you would like to measure. Further it says that measuring is fine for seeing if what you fixed made a difference, but it is not much help in finding out exactly where the performance problems (bottlenecks) are.

If there is a bottleneck (and there probably is) that if removed would result in some percent reduction in time (like 30%), then the biggest, most obvious clue as to what it is is this

• What is the program doing in that 30% of the time?

If you take 10 random-time samples of what it is doing, then on 3 out of 10 (more or less) of those samples, you will "catch it in the act" of doing the bottleneck. Notice one thing - we're asking "what". We are not asking "how much".

The very fact that it takes time is what makes it easy to find. Debugging is hard - you have to trace through the execution and catch it going wrong. Finding bottlenecks is easy - they expose themselves to you.

You don't need to measure in order to find. Once you find, you can measure. Here's more on that subject.