C++性能分析和优化

Question

我对我的应用程序的性能有一些问题。我在Stackoverflow上找到了这个答案：https://stackoverflow.com/a/378024/5363

我很喜欢。我不太理解的一点是，代码优化和分析之间的关系是什么。因为很明显，一个人想要分析优化的代码，但同时在优化过程中丢失了大量信息。那么，在调试器中运行优化的代码并按照引用的答案中的建议进入调试器是否可行？

我在Linux下和gcc一起使用CMake，如果这有什么不同的话。

Answer 1

一般的定律被称为帕累托的定律，the law of 80/20

• 20%的原因产生了80%的后果。

通过分析，您将确定导致应用程序运行缓慢/消耗内存或其他后果的20%最重要的原因。如果你解决了20%的原因，你将解决80%的缓慢/内存消耗等问题……

当然，这些数字只是数字。只是为了让你感受到其中的精髓：

，

• ，你只需要关注，真正的主要原因是，以便改进优化，直到你满意为止。

从技术上讲，对于linux下的gcc，对你提到的“How can I profile C++ code running in Linux?”这个问题的回答建议使用，简而言之：

• gprof.
• google-perftools
• Valgrind
• Intel VTune
• Sun DTrace

Answer 2

如果需要收集堆栈样本，为什么要通过调试器进行。以固定的时间间隔运行pstack。您可以将每次运行的输出重定向到不同的文件，并在以后分析这些文件。通过查看这些文件的调用堆栈，您可能会发现热函数。您不需要调试二进制文件，可以在完全优化的二进制文件上执行上述操作。

我更喜欢使用分析器工具来做上面的事情，或者做你引用的线程中列出的事情。它们可以快速定位热门函数，您可以通过查看调用者被调用者图来了解调用堆栈。我会花时间理解调用者被调用者堆栈，而不是使用上面的方法分析随机堆栈。

Answer 3

正如Schumi所说，您可以使用类似于pstack的东西来获取堆栈样本。但是，您真正需要知道的是，为什么程序要花费采样的瞬间时间。也许你可以从一堆函数名中找出答案。如果您还能看到调用发生的代码行，那就更好了。如果你能看到参数值和数据上下文，那就更好了。原因是，与流行的概念相反，您正在寻找“热点”、“慢方法”、“瓶颈”-即基于度量的视角，而最有价值的事情是正在做的可以被消除的事情。

换句话说，当您在调试器中停止程序时，请将其正在执行的操作视为错误。试着找到一种不做那件事的方法。然而，拒绝这样做，直到你拿到另一个样本，看到它在做同样的事情-无论你怎么描述它。现在您知道这需要很长时间了。还有多少时间？这无关紧要--你修好它后就会知道了。你知道这是很多。在看两次之前，你必须采集的样本越少，它就越大。

然后就有了“放大效应”。在你修复了这个“速度错误”之后，程序花费的时间会少很多，但这并不是唯一的一个。还有其他的，现在他们花了更多的时间。所以再来一次吧。当你读完这篇文章时，如果程序比玩具还大，你可能会惊讶于它的速度有多快。

你看，工具的问题是你为这种采样的简易性付出了代价。由于您将其视为度量，因此您不会关注代码为什么要做它正在做的事情的原因-可疑的原因。这会导致你错过了让代码变得更快的机会，导致你错过了放大效果，导致你远远没有达到最终可能的加速效果。

编辑:为火焰道歉。现在回答你的问题-我直到最后才开启编译器优化，因为它可以掩盖更大的问题。然后，我尝试执行一个启用了优化的构建，但仍然具有符号信息，以便调试器可以获得合理的堆栈跟踪并检查变量。当我达到递减的加速回报时，我可以看到优化器仅仅通过测量总体时间就能看到有多大的不同-不需要分析器。