什么时候性能提升足够显著，可以实现这种优化？

Question

根据课本，每当我尝试优化我的代码时，我都会测量性能。然而，有时性能收益相当小，我不能决定是否应该实现这种优化。

例如，当修复程序在某些条件下缩短了100ms到90ms的平均响应时间时，我是否应该实现该修复程序？如果它将200毫秒缩短到190毫秒呢？我应该尝试多少个条件，才能得出总体上有益的结论？

我想这是不可能给出一个直接的答案，因为它取决于太多的事情，但有没有一个好的经验法则，我应该遵循？是否有任何指导方针/最佳实践？

编辑:感谢你的精彩回答！我想这个故事的寓意是，没有简单的方法来判断你是否应该这样做，但有一些指导方针可以帮助你完成这一过程。你应该考虑的事情，你不应该做的事情等等。这一次我最终实现了修复，尽管它将几行代码变成了20-30行代码。因为我们的应用。是非常关键的性能，并且在各种实际情况下都有10%的持续增长。

Answer 1

我认为经验法则(至少对我来说)是双重的：

1. “重要则重要”--在商业世界中，这通常意味着客户是否关心它很重要。也就是说，如果最终用户“注意到”100ms和90ms之间的差异(我在这里不是开玩笑)，那么它很重要。
2. 如果“它很重要”，那么您将希望针对可能出现或至少可能出现的各种实际用例()彻底测试代码。如果优化在50%的情况下加快了代码的速度，但实际上在另外50%的情况下运行速度比以前慢，显然，它可能不值得实施。

关于上面的第一点:通过建议软件的最终用户可能会“注意到”10ms的差异，我的意思并不是说他们实际上会明显地看到差异。但是，如果您的应用程序运行在具有数百万个连接的服务器上，并且每增加一点速度就会大大减轻服务器的负载，那么对于运行服务器的客户端来说，这可能很重要。或者，如果你的应用程序执行非常耗时的工作，这是另一种情况，10ms的加速结果可能是明显的，即使加速本身并不明显。

Answer 2

对于您的问题，唯一明智的方法是“当收益足够大，足以保证您投入时间探索、实现和测试优化时”。

“收益足够大”是非常主观的。如果你做出这样的改变，你或你的雇主能卖出更多的软件吗？你的用户群会注意到吗？拥有最快的代码会给你带来个人满足感吗？这些问题或类似问题中的哪一个适用于只有你自己才能知道。

总的来说，我写的大多数软件(在20+一年的职业生涯中)都已经“足够快”了，我所关心的优化代码对最终用户来说是一个明显的瓶颈:查询需要很长时间，滚动太慢，诸如此类的事情。

Answer 3

Donald Knuth做了以下两个关于优化的陈述：

“我们应该忘记小效率，比如说97%的时间:过早优化是万恶之源”2

和

“在已建立的工程学科中，12 %的改进是容易获得的，永远不会被认为是边缘的，我相信同样的观点应该在软件工程中占上风”5

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