如何找到程序中最不优化的部分？
是否有任何工具可以提供某种直方图来显示程序的大部分执行时间都花在哪里？
这是针对在 Visual Studio 2008 中使用 C++ 的项目。
Are there any tools to give some sort of histogram of where most of the execution time of the program is spent at?
This is for a project using c++ in visual studio 2008.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您所追求的名字是分析器。 尝试使用 Visual Studio Profiler 查找应用程序瓶颈
The name you're after is a profiler. Try Find Application Bottlenecks with Visual Studio Profiler
您需要一个分析器。
Visual Studio Team 版本包括一个探查器（这正是您正在寻找的），但您可能只能访问 Professional 或 Express 版本。 查看这些线程以获取替代方案：
What's your favorite profiling tool (for C++)
Windows 上的本机 C++ 有哪些好的分析器？< /a>
在测量应用程序的运行时间之前，您确实不应该优化应用程序的任何部分。 否则，你可能会把努力用在错误的地方，而且你可能会让事情变得更糟，而不是更好。
You need a profiler.
Visual Studio Team edition includes a profiler (which is what you are looking for) but you may only have access to the Professional or Express editions. Take a look at these threads for alternatives:
What's your favorite profiling tool (for C++)
What are some good profilers for native C++ on Windows?
You really shouldn't optimize ANY parts of your application until you've measured how long they take to run. Otherwise you may be directing effort in the wrong place, and you may be making things worse, not better.
我使用了一个名为“AQ Time”的分析器，它提供了您想了解的有关代码性能的所有详细信息。 虽然它不是免费的..
I have used a profiler called "AQ Time" which gives every detail you want to know about about the performance of your code. It's not free though..
您可以获得程序计数器的直方图，但它实际上是无用的，除非您正在做一些愚蠢的事情，例如花时间在一大堆整数或双精度数的冒泡排序中。
如果您执行一些简单的操作，例如对字符串数组进行冒泡排序，则 PC 直方图只会告诉您字符串比较例程中有一个热点。
这没什么帮助，不是吗？
我知道你不会做这样的冒泡排序，但只是为了好玩，我们假设你做了，而且它占用了你 90% 的时间。 （也就是说，如果你修复了它，它的速度可能会快 10 倍。）
这实际上是一件很容易找到的事情，因为如果你只是点击调试器中的暂停按钮，你几乎肯定会看到它停止在字符串比较中常规。 然后，如果您向上一级查找堆栈，您将直接查看冒泡排序循环，这就是您的错误。 如果您不确定是否真的发现了问题，只需暂停几次即可。 您看到该问题的次数就可以告诉您该问题的代价有多大。
调用堆栈上多次暂停时出现的任何代码行都在恳求您修复它。 有些你不能，比如“call _main”，但如果你能，你将获得很好的加速，这是保证的。
然后再做一遍，再做一遍。
当你用完时如果你能解决一些问题，那么你就真的把程序调整到了它的寿命之内。
就是这么简单。
您还可以使用 Visual Studio 中的探查器。 这是一个很好的工具，但要注意以下缺点：
让您与“专属时间”混淆，如果您专注于行级信息，则几乎没有意义。
如果你的程序浪费时间做 I/O，它不会看到这一点，因为当它停止做 I/O 时，样本就会停止，除非你使用检测。
但是如果您使用检测，您将无法获得行级信息，而只能获得函数级信息。 如果您的函数都很小，那没关系。
让您对“调用树”感到困惑。 对于一行代码来说，重要的是它有多少个堆栈样本。 如果它位于调用树的许多分支中，则调用树不会向您显示其实际成本。
如果它告诉您一条线路的成本很高，它无法告诉您原因。 为此，您希望根据需要查看每个样本的尽可能多的状态信息，而不仅仅是摘要。
很难区分什么时候想要做样本，什么时候不想做。 您希望它在您等待应用程序时进行采样，而不是在应用程序等待您时进行采样。
You could get a histogram of the program counter, but it is practically useless unless you are doing something dumb like spending time in a bubble sort of a big array of ints or doubles.
If you do something as simple as a bubble sort of an array of strings, the PC histogram will only tell you that you have a hotspot in the string compare routine.
That's not much help, is it?
I know you wouldn't do such a bubble sort, but just for fun, let's assume you did, and it was taking 90% of your time. (i.e. if you fixed it, it could go up to 10 times faster.)
It's actually a very easy thing to find, because if you just hit the pause button in the debugger, you will almost certainly see that it stops in the string compare routine. Then if you look up the stack one level, you will be looking directly at the bubble sort loop which is your bug. If you're not sure you've really spotted the problem, just pause it several times. The number of times you see the problem tells you how costly it is.
Any line of code that appears on the call stack on multiple pauses, is something that is begging you to fix it. Some you can't, like "call _main", but if you can you will get a good speedup, guaranteed.
Then do it again, and again.
When you run out of things you can fix, then you've really tuned the program within an inch of its life.
It's that simple.
You could also use the profiler in Visual Studio. It is a nice tool but be aware of these shortcomings:
Confusing you with "exclusive time", which if you concentrate on line-level information, is almost meaningless.
If your program is wasting time doing I/O, it won't see that, because when it stops to do I/O, the samples stop, unless you use instrumentation.
But if you use instrumentation, you won't get line-level information, only function-level. That's OK if your functions are all small.
Confusing you with the "call tree". What matters for a line of code is how many stack samples it is on. If it is in many branches of the call tree, the call tree won't show you what it really costs.
If it tells you a line is costly, it cannot tell you why. For that you want to see as much state information on each sample as you need, rather than just summaries.
It's hard to tell it when you want to do samples, and when not. You want it to sample when you're waiting for the app, not when it's waiting for you.
现在您知道需要一个探查器，但您可能没有 Visual Studio 探查器，因此非常困 可能会有帮助。
So now that you know you need a profiler, you might not have the Visual Studio one, so Very Sleepy might be of help.