什么时候优化还为时过早？

Question

什么时候优化还为时过早？

就像Knuth说的，

我们应该忘记小效率，说大约97%的时候：过早的优化是所有邪恶的根源。

这是Stack溢出问题中经常出现的问题，例如“哪种是最有效的循环机制”、“SQL优化技术？”(诸若此类)。这些优化技巧问题的标准答案是分析代码，看看它是否首先是一个问题，如果不是，那么您的新技术就不需要了。

我的问题是，如果某个特定的技术是不同的，但不是特别模糊或模糊，那么这真的能被认为是一种过早的优化吗？

这是兰德尔海德的一篇相关文章过早优化的谬误.

Answer 1

IMHO，90%的优化应该发生在设计阶段，基于当前，更重要的是，未来的需求。如果您必须取出一个分析器，因为您的应用程序没有扩展到所需的负载，那么您离开它的时间太晚了，而IMO将浪费大量的时间和精力来纠正这个问题。通常，唯一值得进行的优化是那些在速度方面给您带来了数量级性能改进的优化，或者在存储或带宽方面获得一个倍增器的优化。这些类型的优化通常与算法选择和存储策略有关，并且很难反转到现有代码中。它们可能会影响您实现系统所用的语言的决定。因此，我的建议，尽早优化，根据您的需求，而不是您的代码，并期待您的应用程序的可能延长寿命。

Answer 2

我的问题是，如果某个特定的技术是不同的，但不是特别模糊或模糊，那么这真的能被认为是一种过早的优化吗？呃.。因此，您手头有两种技术，成本相同(使用、阅读、修改的工作量相同)，其中一种更有效。不，在这种情况下，使用效率更高的办法是不成熟的。打断您的代码编写以寻找公共编程构造/库例程的替代方案，可能会有一个更有效的版本出现在某个地方，尽管您知道您正在编写的代码的相对速度实际上并不重要.那是太早了。