分析代码以提高效率？

Question

您使用哪些类型的工具来确定代码的效率？您使用的是运行大量统计测试的自制应用程序，还是一些商业产品？您是否使用自己的知识来测试代码的某些区域，或者使用某些工具来分析代码的弱点？

Answer 1

这称为profiling。对于各种不同的语言，有许多现成的工具可以帮助您确定应用程序中的瓶颈所在。例如，如果您希望的话，TPTP工具集可以向您显示单个方法级别的性能瓶颈所在。当然，有时你真正需要的只是几次系统计时器的读取，以获得关于一段代码的大致概念。

Answer 2

插入:让我们看看“统计意义”。

假设在某个地方有一个函数调用指令。你不一定能看到它--一个类，一个宏，或者编译器，可能已经把它放进去了。附近还有对同一函数的其他调用，但此调用处于循环中，或者其参数会使此调用花费很长时间。事实上，如果这个调用的时间为零，那么总的执行时间就会减少一些，比如90%。(不可能？(一点也不。)时机是否能准确定位呢？不是的。调用图会精确地指出它吗？不是的。呼叫计数会准确地指出它吗？不是的。因为问题不在函数级，而是在call指令级。

不知何故，程序在某个时间点被随机停止，并检查其状态。如果指令可以被“清零”，那么它会在90%的时间内停止吗？当然-以90%的概率，指令将被精确定位在堆栈上，等待其“工作”完成。

事实上，如果您随机停止它20次，该指令将在堆栈上平均18次，标准差为+/- 1.3倍。

这在统计学上有意义吗？当然是这样的。

你需要大量的样品吗？你敢打赌你没有。

假设百分比很小，比如10%或5%。同样的原则也适用。

事实上，无论采样多少，任何大于1个样本的指令在统计上都是有意义的，并且是一个“热点”、“瓶颈”或任何你想叫它的东西。如果你可以移除它，少调用它，或者以某种方式减少它，它将节省大量的时间。(有些你不能，比如"call _main"，但另一些你可以。您只需要找到它们。)

当然，我的代码永远不会这么愚蠢，不是吗？那就证明给我看。

好了，现在回到故事中来。。。

原始答案:我听说过分析器，很久以前，我认为它们一定很整洁，但我无法访问它们/它。我当时正在研究一个嵌入式处理器( 8086英特尔芯片)，在显示屏上绘制一些浮点数字似乎要花很长时间。硬件人员建议从他们的大量添加计时器芯片中提供，这样我就可以看到事情花了多长时间。然而，有一个周末，我用Intel "Blue Box“在线仿真器启动了它，并让它运行起来。当它很慢的时候，我想知道“它到底在做什么？”所以我就停下来找出答案。PC在浮点库中(没有FP芯片)。这并不奇怪，因为它绘制的是浮点数，但我想知道更多。因此，我(费力地)读取十六进制内存，以便跟随调用堆栈。你猜怎么着？这是在获取要绘制的数字，将其除以10，转换为整数，转换回浮点数，减法，等等的过程中，只是为了获得下一个要绘制的数字。不用说，有更好的方法可以做到这一点，结果加速了大约10倍。在 one (1) 中找到的示例！

在另一种情况下，在68K芯片上，有一些缓慢。同样，分析器不可用，但调试器"adb“可用，因此当它很慢时，我将其停止了几次。PC在数学库中，实际上在32位整数乘法例程中。查找堆栈时，我发现了以下代码：

struct {...} a[...];

int i;
for (i = 0; i < ...; ++i){ ... a[i] ... }

这里没有调用乘法-这是怎么回事？结果是，对于a[i]，编译器必须将i乘以数组元素的大小。由于i是32位(在编译器中)，因此它生成对32位乘法例程的调用，且堆栈精确定位该调用指令。通过将i声明为short，循环的速度提高了三倍！

这有什么意义呢？如果你在程序运行缓慢的时候随机采样，PC会告诉你它在做什么，但调用栈会告诉你原因，并直接把你带到问题所在。现在，除非问题真的很严重，否则您可能需要采集多个样本。任何出现在>1个样本上的语句都是可以怀疑的。注意，它精确定位语句，甚至指令，而不是像函数这样的大段代码。This technique可能“又快又脏”，但它是非常有效的。

补充:如果你重复这样做，你可以在同一个软件中解决一个又一个问题。例如，如果您获得3倍的加速，以前可能微不足道的小性能问题现在将占用剩余时间的3倍以上。这使得它们更容易与样本打交道。您可能需要添加一个临时的外部循环，以使其运行足够长的时间来进行采样。通过这种方式，我看到了more than 40 times的复合加速因子。

Answer 3

分析器对于查看您花费时间最多的代码非常有用。有许多分析工具，通常它们特定于您所处的平台/开发环境。

对于小的情况，我在代码中使用了简单的计时器(动作结束时的系统时间-动作开始时的系统时间)。

一条重要的规则是:永远不要认为你刚刚进行的性能优化实际上会运行得更快。始终验证！