有效的代码检测？

Question

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

1. 开发人员应该采用什么方法来有效地检测代码以衡量绩效？

2. 在阅读基准测试和性能测试时，需要注意的一些红色标志可能并不代表实际结果？

Answer 1

有两种衡量绩效的方法：使用代码工具和使用抽样。

我过去使用的商业剖析器（Hi-Prof，Rational Quantify，AQTime）使用了代码检测（其中一些也可以使用采样），根据我的经验，这给出了最好，最详细的结果。特别是Rational Quantity允许您放大结果，关注子树，删除完整的调用树以模拟改进，...

这些仪器分析器的缺点是它们：

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

仪器有时也会扭曲报告的内存分配，关键部分等低级功能的时间......

我使用的免费分析器（Very Sleepy，Luke Stackwalker）使用了采样，这意味着更容易进行快速性能测试并查看问题所在。这些免费的分析器没有商业分析器的全部功能（虽然我自己提交了“专注于子树”功能），但由于它们很快，它们非常有用。

此时，我个人最喜欢的是非常困倦，Luke StackWalker排在第二位。

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

• 在应用程序的不同版本中比较分析器的结果非常困难。如果您的版本2.0中存在性能问题，请对版本2.0进行概要分析并尝试对其进行改进，而不是查找2.0慢于1.0的确切原因。
• 您绝不能将分析结果与在分析器外部运行的应用程序的计时（实时，CPU时间）结果进行比较。如果您的应用程序在分析器外部消耗5秒CPU时间，并且在分析器中运行时，分析器报告它消耗10秒，则没有任何错误。不要以为你的应用程序实际需要10秒钟。
• 这就是为什么你必须在同一环境中持续检查结果的原因。在分析器外部运行或在分析器内运行时，始终比较应用程序的结果。不要混淆结果。
• 还使用一致的环境和系统。如果您使用更快的PC，您的应用程序仍可能运行得更慢，例如因为屏幕较大，需要在屏幕上更新。如果要转移到新PC，请在新PC上重新测试应用程序的最后一个（一个或两个）版本，以便了解扩展到新PC的时间。
• 这也意味着：使用固定数据集并检查这些数据集的改进。可能是您的应用程序的改进提高了数据集X的性能，但使数据集Y的速度变慢。在某些情况下，这可能是可以接受的。
• 与测试团队讨论您希望事先获得的结果（请参阅Oded在我自己的问题What's the best way to 'indicate/numerate' performance of an application?上的答案）。
• 意识到更快的应用程序仍然可以比较慢的应用程序使用更多的CPU时间，如果速度更快的应用程序使用多线程而速度较慢的应用程序则不会。讨论（如前所述）测试时间需要测量什么和不测量什么（在多线程情况下：实时而不是CPU时间）。
• 意识到许多小的改进可能会带来一个很大的改进。如果您在应用程序中发现10个部分，每个部分占3％的时间，并且可以将其减少到1％，那么您的应用程序将快20％。

Answer 2

这取决于你想要做什么。

1）如果您想维护一般的时间信息，那么您可以对回归保持警惕，可以采用各种仪器分析器。确保它们测量各种时间，而不仅仅是CPU时间。

2）如果你想找到使软件更快的方法，那就是一个截然不同的问题 您应该强调 find ，而不是度量。

• 为此，您需要对调用堆栈进行采样的内容，而不仅仅是程序计数器（如果需要，可以通过多个线程）。这排除了profilers like gprof。

• 重要的是，它应该在挂钟时间上进行采样，而不是CPU时间，因为由于处理由于处理而导致的I / O可能会浪费时间。这排除了一些个人资料。

• 只有在您关心时才应该采样，例如不等待用户输入时。这也排除了一些剖析器。

• 最后，非常重要的是你得到的摘要。 获得每行百分比至关重要。 一行使用的时间百分比是包含该行的堆栈样本的百分比。 即使使用调用图，也不要满足于仅功能定时。 这排除了更多的分析器。 （忘记“自我时间”，忘记调用计数。这些很少有用，而且经常会产生误导。）

找到问题的准确性是你所追求的，不是衡量它们的准确性。这是非常重要的一点。 （你不需要大量的样本，虽然没有任何伤害。伤害在你的头脑中，让你考虑测量，而不是它在做什么。）

一个很好的工具是RotateRight的缩放分析器。我个人依赖manual sampling。