Windows 性能计数器的工作范例是什么？
我刚刚读完这篇文章，了解如何创建性能计数器并更新计数器的值。但我对 Windows 性能计数器的工作范例有点困惑。假设有2个程序A和B，A想通过一些性能计数器了解B的性能。以下哪种情况是正确的？
B 创建/注册一些性能计数器到 Windows 中，B 负责更新计数器的值。 A 可能是系统perfmon.exe。 A没有主动探测B的执行状态。 A 只需检查注册的计数器并获取 B 提供和更新的值。即使没有 A，B 仍然总是更新其注册的性能计数器。但这不是对B的性能造成某种负担吗？
A主动探测B的执行状态，计算出性能计数器的值。在这个范式中，B 没有任何额外的负担。
简而言之，谁负责创建和更新性能计数器？正在测量其性能的目标程序？或者是测量目标程序性能的主题程序？对于程序A来说，这是一个探测场景吗？或者只是一个阅读场景？
非常感谢。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
性能计数器可能是一个有趣的问题，但您的总体目标是什么？您有兴趣了解如何使程序运行得更快吗？
如果不是，请忽略这个答案。
如果是这样，那么有一种观点认为，性能计数器的存在是为了对您想要测量的事物进行计数。此外，它还表示，测量可以很好地了解您修复的内容是否产生了影响，但对于找出性能问题（瓶颈）的确切位置并没有多大帮助。
如果存在一个瓶颈（很可能存在），如果消除该瓶颈会导致时间减少一定百分比（例如 30%），那么关于它是什么的最大、最明显的线索就是这个
如果您对它正在执行的操作进行 10 个随机时间样本，那么在这些样本中的 10 个（或多或少）中的 3 个中，您将“发现它”正在执行瓶颈。注意一件事——我们问的是“什么”。我们不是问“多少”。
事实上，它需要时间，因此很容易找到。调试很困难——您必须跟踪整个执行过程并发现错误。找到瓶颈很容易——它们会将自己暴露给你。
您无需测量即可找到。一旦找到，就可以测量。 以下是有关该主题的更多信息。
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
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.