早期优化与早期优化的效率规划

Question

我似乎注意到在优化方面出现了两个学派：

1. 过早优化是所有的根源所在。只有在编写了最易读和最简单的东西之后，才应该进行优化。如果在分析后确定该软件太慢，则应进行优化。
2. 优化应该在项目生命周期的早期完成。需要对优化进行规划，但应该合理地进行。

从表面上看，他们似乎是相当对立的观点。问题是，我看到了这两个学派的优点。我还可以想到，这两种思维方式都帮助我编写了更好、更快的软件。

有办法调和这两种思想吗？有中间路线吗？有什么时候，一个想法是最好的工具工作吗？还是我提出了一个错误的二分法，这两种观点可以和平共处？

Answer 1

我通常所做的是应用那些不花费任何代价(或者几乎什么都不需要)的优化。我也一直在留意那些不适合扩展并且经常被调用的算法。除此之外，我不会优化直到软件运行，我有机会启动剖析器。只有这样，我才会投入一些认真的时间进行优化。

Answer 2

早期在设计和架构级别进行优化。之后在实现层次上进行微观优化。

您需要知道您所做的设计决策的性能成本，这将是以后很难更改的。实现通常可以在稍后进行调优，这就是为什么在您知道这是一个问题之前不值得这样做的原因。

Answer 3

集中精力编写代码，完成它应该做的事情，并且只编写所需的次数。优化干净、优雅的代码通常很简单。