Visual Studio 2008 Profiler - Instrumented 产生奇怪的结果
我在应用程序的“RelDebug”版本上运行 Visual Studio 2008 探查器。优化已开启，但内联程度适中，存在堆栈帧，并且发出符号。换句话说，RelDebug 是一个可以调试的、经过一定程度优化的构建（尽管有关检查变量的常见发行版警告适用）。
我在单独的运行中运行采样和仪器分析器。
结果？采样分析器产生的结果看起来很合理。然而，当我查看 Instrumented Profiler 结果时，我发现一些函数甚至不应该出现在列表顶部附近。
例如，像“SetFont”这样的函数仅由 1 行组成，用于将高度分配给类成员。或仅分配一个矩形的“SetClipRect”。
当然，我正在查看“独家”统计数据（即减去儿童）。
这发生在其他人身上吗？一旦我的应用程序增长到一定规模，这种情况似乎总是会发生。这使得仪表分析器在此时毫无用处。
我找到了问题所在。 Visual Studio 2008 和 Visual Studio 2010 分析器都表现平平（委婉地说）。我购买了 Intel C++ Studio，它附带 vTune Amplifier（分析器）。在完全相同的代码上使用英特尔分析器，我能够获得真正有意义的分析器结果。
I run the Visual Studio 2008 profiler on a "RelDebug" build of my app. Optimizations are on, but inlining is only moderate, stack frames are present, and symbols are emitted. In other words, RelDebug is a somewhat optimized build that can be debugged (although the usual Release caveats about inspecting variables applies).
I run both the Sampling, and the Instrumented profiler on separate runs.
Result? The Sampling profiler produces a result that looks reasonable. However when I look at the Instrumented profiler results, I see functions that should not even be near the top of the list, coming out up to.
For example, a function like "SetFont" that consists of only 1 line assigning the height to a class member. Or "SetClipRect" that merely assigns a rectangle.
Of course I am looking at "Exclusive" stats (i.e. minus children).
This happen to anyone else? It always seems to happen once my application has grown to a certain size. It makes the instrumented profiler useless at that point.
I figured out the problem. Both the Visual Studio 2008 and the Visual Studio 2010 profilers are mediocre (to put it politely). I bought Intel C++ Studio which comes with vTune Amplifier (a profiler). Using the Intel profiler on the exact same code I was able to get profiler results that actually made sense.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你说“你当然在看Exclusive”。查看包容性统计数据。在除了最简单的程序或算法之外的所有程序或算法中，几乎所有时间都花费在子例程和函数中，因此如果您遇到性能问题，它很可能由您不知道是浪费时间的调用组成。
我依赖的方法是这个< /a>.假设您正在尝试找出可以修复的内容以使代码更快，它会找到它，同时不会浪费您的时间来对不存在问题的事情进行高精度统计。
You say "of course you are looking at Exclusive". Look at inclusive stats. In all but the simplest programs or algorithms, nearly all the time is spent in subroutines and functions, so if you've got a performance problem, it most likely consists of calls you didn't know were time-hogs.
The method I rely on is this. Assuming you are trying to find out what you could fix to make the code faster, it will find it, while not wasting your time with high-precision statistics about things that are not problems.
没有错误。抽样无法告诉您每次通话花费了多少时间。 Profiler 只是计算计时器在该特定函数中结束的次数。由于 SetFont 不经常被调用，因此您不会在该函数中获得太多点击，并且您会觉得该函数并不耗时。
另一方面，当您运行检测时，分析器会计算每个调用并测量每个函数的执行时间。这就是为什么您可以获得有关函数 CPU 消耗的准确信息。
在检查检测结果时，您还必须始终查看调用数量。由于 SetFont 是多-少 API，因此它是独占的还是包含的并不重要。唯一重要的是它的总时间和调用的频率。
There's no bug. Sampling cannot tell you how much time you spent per call. Profiler is just counting how many times timer ended up in that specific function. Since SetFont is not frequently called, you don't get many hits in that function and you get impression that that function is not time consuming.
On the other hand, when you run instrumentation, profiler counts every call and measures execution time of every function. That is why you get accurate information about functions CPU consumption.
When examining instrumentation results you must always look at number of calls as well. Since SetFont is more-less API it doesn't matter if it's exclusive or inclusive. The only thing that matters is its overall time and how frequently it's called.