何时性能增益足以实现优化？

Question

在教科书之后，每当我尝试优化代码时，我都会测量性能。然而，有时候，性能提升相当小，我不能果断地决定是否应该实现这种优化。

例如，在某些情况下修复时间缩短了100ms到90ms的平均响应时间，我应该实现该修复吗？如果缩短200ms到190ms怎么办？在得出总体上有益的结论之前，我应该尝试多少条件？

我想这是不可能给出一个直截了当的答案，因为它取决于太多的东西，但是我应该遵循一个好的经验法则吗？有没有指南/最佳实践？

编辑：谢谢你的答案！我想这个故事的寓意是，没有简单的方法来判断你是否应该，但是有一些指导方针可以帮助这个过程。你应该考虑的事情，你不应该做的事情等等。这个特定的时间我最终实现修复，即使它在20-30行代码中生成了几行代码。因为我们的应用。在性能上非常重要，在各种现实案例中，这一点始终保持10％的增长。

Answer 1

我认为经验法则（至少对我而言）是双重的：

1. “重要但是重要” - 在商业世界中，这通常意味着如果客户关心它就很重要。也就是说，如果最终用户会“注意到”100毫秒到90毫秒之间的差异（我在这里不是很滑稽），那么这很重要。
2. 如果“重要”，那么您将需要针对可能出现或至少可能出现的真实多样性用例进行彻底测试。如果优化在50％的情况下加速代码，但实际上比其他50％的时间运行得慢，显然，它可能不值得实现。

关于上述第1点：通过建议您的软件的最终用户可能“注意到”10ms的差异，我并不是说他们实际上会明显看到差异。但是，如果您的应用程序在具有数百万个连接的服务器上运行，并且每次小的速度增加都会对服务器造成很大负担，这对运行服务器的客户端来说可能很重要。或者，如果您的应用程序执行极其时间关键的工作，这是另一种情况，即10分钟加速的结果可能会引人注意，即使加速本身不是。< / p>

Answer 2

对你的问题唯一明智的做法是“当利益足够大以保证你投入探索，实施和测试优化的时候。”

“利益足够大”是非常主观的。如果您进行此更改，您或您的雇主可以销售更多的软件单元吗？您的用户群会注意到吗？是否可以为您提供个人满足感，以获得最快的代码？哪些或类似的问题适用只有你才能知道。

总的来说，我写的大部分软件（在20多年的职业生涯中）已经“足够快”开箱即用，而我关心优化的代码本身就是最终用户的瓶颈：查询需要很长时间，滚动速度太慢，等等。

Answer 3

Donald Knuth就优化发表了以下两条声明：

  

“我们应该忘记小事   效率，约占97％   时间：过早优化是   万恶之源“[2]

和

  

“在已建立的工程中   纪律改善了12％，很容易   获得，从未被认为是边缘的   我相信同样的观点   应以软件为准   工程“[5]

src：http://en.wikipedia.org/wiki/Program_optimization

Answer 4

• 优化是否过多地模糊了您的代码？
• 你真的需要优化吗？如果您的应用程序运行良好，那么代码的可读性可能更重要
• 在尝试小型hacky优化之前，您是否参与了应用程序的一般设计和算法？

Answer 5

您应该将优化工作集中在占运行时最多的代码部分。如果一段特定的代码占总运行时间的80％，那么优化它以减少5％的时间将产生与将其余代码的时间减少20％相同的影响。

通常，优化会降低代码的可读性（并非总是如此，但通常都是如此）。因此，在确定存在问题之前，应避免优化。

Answer 6

如果它加速你的程序，为什么不实现它？您已经通过创建新实现来完成工作，因此您不会通过应用新实现来完成额外的工作。

除非代码更难理解。

此外，100 ms至90 ms的性能提升10％。不应轻率增加10％。

真正的问题是，如果首先只运行100毫秒，那么尝试优化它的重点是什么？

Answer 7

只要它足够快 ，那么您就不需要再进行优化了。但是，如果是这样的话，你甚至不会打扰分析......

Answer 8

如果性能提升很小，请考虑其他因素：可维护性，进行更改的风险，可理解性等。如果它降低了维护或理解代码的能力，则可能不值得这样做。如果它改善了这些属性，那么实施更改就更有理由了。

Answer 9

在大多数情况下，您的时间比计算机更有价值。如果你认为你需要花半个小时的时间才能弄清楚代码后面会做什么（比如说它有什么错误），并且它只能保存你几秒钟，那么你就会遭受净损失。

Answer 10

这在很大程度上取决于使用场景。我在这里假设有问题的代码已被分析，因此它被认为是瓶颈 - 即。不只是“这可能更快”，但“如果速度更快，该程序将给予结果/完成更快”。在不是这种情况的情况下 - 例如。如果你花99％的时间等待更多的数据来通过以太网连接 - 那么你应该关心正确性而不是优化速度。

• 如果您正在编写一段用户界面代码，您关心的是感知速度。一般来说，大约100毫秒以下的任何东西都被视为“即时” - 没有必要加快速度。
• 如果您正在为一个巨型服务器场编写一段代码，那么如果快速生成代码的工资成本低于服务器场额外电力的成本，那么这是值得的。 （但一定要优先考虑你的时间。）
• 如果您正在编写一段很少使用或无人看管的代码，只要它在半理智的持续时间内完成，请不要担心。安装脚本往往属于这种类型（除非你开始运行很多分钟，此时用户可能会开始放弃安装，因为它花了太长时间）。
• 如果您正在编写代码来为其他人自动执行任务，那么如果（您的编码时间+使用优化代码花费的时间）小于（使用慢代码所花费的时间），那么这是值得的。如果你在商业环境中这样做，可以用你各自的工资来衡量。
• 如果您正在编写将被成千上万人使用的库代码，如果您有时间，请始终加快速度。
• 如果你有时间压力，只需要做一些工作，例如作为一个演示，不要优化（除非通过合理选择来自库的算法），除非结果太慢以至于它甚至都没有“正常工作”。

对我个人来说，最大的烦恼之一就是找到可能最初属于一个类别然后又陷入另一个类别的软件，但是没有人回去做必要的优化。直到最近，Javascript性能才是一个很好的例子。故事的道德是：不要只决定一次;根据情况需要重新审视这个问题。