Performance 有效的代码检测？

我经常阅读关于一些新框架及其“基准”的声明。我的问题是一般性的，但具体到：

开发人员应该采取什么方法来有效地对代码进行仪器化以衡量性能

在阅读有关基准测试和性能测试的文章时，有哪些不代表实际结果的危险信号需要注意

---

这取决于你想做什么

1） 如果您希望维护一般的计时信息，以便对回归保持警惕，那么可以使用各种仪器探查器。确保他们测量各种时间，而不仅仅是CPU时间

2） 如果您想找到使软件更快的方法，这是一个明显不同的问题。
你应该把重点放在发现上，而不是测量上

• 为此，您需要对调用堆栈进行采样，而不仅仅是程序计数器（如有必要，通过多个线程）。这就排除了

• 重要的是，它应该是挂钟时间，而不是CPU时间，因为由于I/O而损失时间的可能性和由于压缩而损失时间的可能性是一样的。这排除了一些分析器

• 它应该只能在您关心的情况下采集样本，例如在等待用户输入时。这也排除了一些分析器

• 最后，也是非常重要的，是你得到的总结。 每行的时间百分比非常重要。 行使用的时间百分比是包含该行的堆栈样本的百分比。 不要满足于只使用函数计时，即使使用调用图也是如此。 这排除了更多的分析器。 （忘记“自我时间”，忘记调用计数。这些很少有用，而且常常误导。）

发现问题的准确性是你所追求的，而不是测量问题的准确性。这是非常重要的一点。（你不需要大量的样本，尽管这没有什么害处。害处就在你的脑子里，让你考虑测量，而不是它在做什么。）

---

一个很好的工具是Zoom profiler。就我个人而言，有两种方法可以衡量性能：使用代码检测和使用采样

我在过去使用的商业分析器（Hi-Prof，Rational Quantify，AQTime）使用代码插装（其中一些还可以使用采样），根据我的经验，这提供了最好、最详细的结果。特别是RationalQuantity允许您放大结果，关注子树，删除完整的调用树以模拟改进

这些检测分析器的缺点是：

• 趋于缓慢（代码运行速度慢10倍左右）
• 花一些时间来测试你的应用程序
• 不要总是正确处理应用程序中的异常（在C++中）
• 如果必须禁用DLL的检测，则可能很难设置（我们必须禁用Oracle DLL的检测）

检测有时也会扭曲低级别函数（如内存分配、关键部分等）的报告时间

我使用的免费分析器（非常困，Luke Stackwalker）使用采样，这意味着进行快速性能测试和查看问题所在要容易得多。这些免费的分析器没有商业分析器的全部功能（尽管我为我自己提交了“关注子树”的功能），但是由于它们速度快，它们可能非常有用

在这个时候，我个人最喜欢的是非常困倦，卢克·斯塔克沃克排在第二位

在这两种情况下（仪器和采样），我的经验是：

• 在应用程序的不同版本上比较分析器的结果是非常困难的。如果您的2.0版存在性能问题，请分析您的2.0版并尝试改进它，而不是寻找2.0版比1.0版慢的确切原因
• 决不能将分析结果与在分析程序外部运行的应用程序的计时（实时、cpu时间）结果进行比较。如果您的应用程序在探查器之外占用5秒的CPU时间，而在探查器中运行时，探查器报告它占用了10秒，那么没有什么问题。不要认为你的应用程序实际上需要10秒钟
• 这就是为什么您必须在相同的环境中始终检查结果。在探查器外部运行或在探查器内部运行时，始终比较应用程序的结果。不要混淆结果
• 还要使用一致的环境和系统。如果您的电脑速度更快，您的应用程序运行速度可能仍然较慢，例如，因为屏幕更大，需要在屏幕上更新的内容更多。如果移动到新电脑，请在新电脑上重新测试应用程序的最后一个（一个或两个）版本，以便了解新电脑的时间比例
• 这也意味着：使用固定数据集并检查这些数据集的改进。应用程序中的改进可能会提高数据集X的性能，但会降低数据集Y的性能。在某些情况下，这是可以接受的
• 与测试团队讨论您希望事先获得的结果（参见Oded对我自己问题的回答）
• 要认识到，如果速度较快的应用程序使用多线程，而速度较慢的应用程序不使用多线程，那么速度较快的应用程序仍然可以比速度较慢的应用程序使用更多的CPU时间。与测试时间讨论（如前所述）哪些需要测量，哪些不需要测量（在多线程情况下：实时而不是CPU时间）
• 认识到许多小的改进可能导致一个大的改进。如果您在应用程序中发现10个部分，每个部分占用3%的时间，并且您可以将其减少到1%，那么您的应用程序将加快20%

---

如果不将领域缩小到特定的技术和问题领域，就无法给出有用的答案