不要过早优化

概要

无故加鞭（拉丁谚语Spur not a willing horse）：过早地优化是没有结果的,就像它很令人着迷一样。优化的第一个原则是：不要去动它。优化的第二个原则（只对专家来说）是：还是不要去动它。衡量两次，优化一次。

讨论

就像[Stroustrup00]§6的美妙引用：

过早优化是罪恶之源 --- Donald Knuth[quoting Hoare]

另一方面，我们不能忽略效率 --- Jon Bentley

Hoare 和Knuth，当然并且一直，是完全正确性的（条款6和这条）。Bentley也是（条款9）。

 

我们把过早优化定义为以性能的名义使设计和代码更加复杂，更不可读，而我们的这些努力并没有被需要的性能检验证明是恰当的（如实际的测量结果和与性能目标对照），并且因此，按定义，将未经证实的价值加到程序中。时常，不必须的和未经测试的努力优化根本不能使程序更快。

 

总是记住：

让正确的程序更快比让快速的程序正确要容易太多，太多。

 

所以，缺省情况下，不要集中在让代码更快上，首先把注意力放在使代码尽可能性的清楚和可读上（条款6）。清楚的代码易于书写正确，易于理解，易于重构---并且易于优化。复杂化，包括优化，总是在稍后引入---并且只是在必须的时候。

 

这儿有两个原因为什么频繁的过早优化一点也不能使程序更快。首先，我们的程序员在估计什么样的代码会快些或慢些，代码中什么地方是瓶颈方面是声名狼籍地差。这些程序员包括我们（这本书的作者），也包括你。考虑：现代的计算机有极其复杂的计算模型，通常包括：管道处理单元在并行的工作，很深的缓存层次，预测执行。指令预测…这些仅仅在CPU芯片的层次。在硬件的基础上，编译器在将代码翻译成机器码时，将会用最好的猜测来利用硬件。唔，在所有的复杂性上，仅仅是你的猜测。所以，你如果仅仅是猜测，只有很小的机会才能使你在病态的目标上的微调有显著的提高。所以，测量在优化之前，优化的目标在测量之前。你的注意力应该在优先级为#1的条目 --- 为人写代码，直到证明必须优化。（当有人请你优化的时候，请他出示证剧）

 

第二，在现代的程序中，许多日益增加的操作并不在CPU的范畴内。它们也许属于内存的范畴，网络的范畴，硬盘的范畴，正在等待WEB服务，或者正在等待数据库。在这样的操作中调整应用程序的代码最多只是等得更快。这也意味着程序员总是浪费宝贵的时间在改进那些不需要改进的代码，而没有通过所做的改进增加价值。

 

当然，确实需要优化某些代码的那天终会到来。当你这样做的时候，请首先看能不能做算法优化（条款7），并试着封装和模块化优化（举例来说，将优化包装在函数或者类中，条款5和条款11），同时在注释中清楚地说明优化的原因和所参考的算法。

 

一个初学者通常的错误是自负的写新代码，以牺牲代码的可理解性为代价换来执行速度的优化。通常，这产生出一大堆糟糕的代码，即使一开始是正确的，也是难于阅读和更改的。