什么优化是不成熟的？

Question

我已经在这里呆了将近一个月了，似乎有人一提到效率，人们就会迫不及待地使用“早熟优化是万恶之源”的论点。

什么是过早的优化？本质上是编写设计良好的系统，还是使用某些方法和过早的优化，两者之间有什么区别？

我觉得在这个问题中，某些方面应该是有趣的话题：

• 优化以何种方式影响代码的复杂性？
• 优化如何影响开发时间/成本？
• 优化是否强调对平台的进一步理解(如果适用)？
• 优化是抽象的吗？
• 优化对设计有何影响？
• “通用解决方案”是一个问题的更好的选择，而不是特定的解决方案，因为特定的解决方案是一个优化？

编辑/更新:发现这两个链接对于早期优化是什么非常有趣：

http://smallwig.blogspot.com/2008/04/smallwig-theory-of-optimization.html

http://www.acm.org/ubiquity/views/v7i24_fallacy.html

Answer 1

任何涉及相关悲观(即可读性、可维护性)的优化都没有明显的好处，可以通过测试/分析来证明。

Answer 2

过早的优化是为了保证优化而做得太早。

这与糟糕的优化不同：

1. 也许某件事情确实能加速一段重要的代码并不值得一些负面的东西，即使它是在分析和用户体验证明了它的价值之后应用的--在这种情况下，它是不好的，但不是过早的。
2. 另一方面，也许有些事情做得太早了，实际上正是我们所需要的--在这种情况下，它是好的，尽管它还为时过早。一般来说，那些对过早的优化感到内疚的人会做很多这样的事情，只是他们会通过做那些让事情变得更糟的事情来平衡它。

过早也不意味着早，只是太早。

如果您正在设计一个涉及两个代理之间使用通信的应用程序，并且有一种方法可以在通信中构建缓存机制，或者在现有通信系统中构建缓存机制(例如，如果使用HTTP)，那么这种缓存不会过早，除非响应实际上不会被缓存(在这种情况下，由于它没有意义)。这种基于问题分析的基本设计决策(但不分析实际代码-代码尚未编写)--是为了提高效率而做出的，这可能是可行性和不可行性之间的区别。

考虑到看似相当的选择，过早并不意味着选择似乎最有效率的选项。毕竟，你必须选择其中一个选项，所以可能的效率是你应该衡量的因素之一。在这种情况下，直觉确实有一定的价值：(A)你还没有足够的数据来纯粹根据事实做出明智的决定，(B)你正在考虑的其他一些因素也是直观的(那些影响代码可读性的因素；衡量它对你来说有多大的可读性仅在少数情况下是有用的，而且你也无法衡量尚未编写的东西的可读性，最后，它只能从统计学上衡量，所以如果你是主要开发人员，你的意见比一个统计上有效的样本更重要)。仅仅因为害怕被指责为过早的优化，而你只是过早地对另一个特性进行优化，你就远离了一个选项。

不成熟也不意味着小规模的优化。如果你能在没有不利影响的情况下取得小小的进步，那就去做吧。事实上，当Knuth说“过早的优化是万恶之源”时，他实际上提出了这个问题，同时为努力获得小的效率收益辩护：

从例2到例2a，速度的提高只有12%左右，很多人会认为这是微不足道的。当今许多软件工程师的传统智慧要求忽视小型软件的效率；但我认为，这只是对他们所看到的滥用行为的过度反应，他们认为愚蠢的程序员无法调试或维护他们的“优化”程序。在现有的工程学科中，12 %的改进是容易获得的，从来没有被认为是边际的；我相信软件工程中也应该有同样的观点--当然，我不会在oneshot的工作中费心去做这样的优化，但是当这是一个准备高质量程序的问题时，我不想局限于那些剥夺了我这样的效率的工具。毫无疑问，效率的圣杯会导致滥用。程序员会浪费大量的时间来思考或担心程序中非关键部分的速度，而这些提高效率的尝试在考虑调试和维护时实际上会产生很大的负面影响。我们应该忘记小效率，说大约97%的时候:过早的优化是所有邪恶的根源。然而，我们不应在这个关键的3 %中放弃我们的机会。一个优秀的程序员不会因为这样的推理而自满，他将明智地仔细研究关键的代码，但只有在确定了该代码之后。对程序的哪些部分真正重要的先验判断往往是错误的，因为使用度量工具的程序员的普遍经验是，他们的直觉猜测失败了。-Knuth，唐纳德。“用go to语句进行结构化编程”，斯坦福，1974年

过早的时候，要知道你正在做的事情，考虑到效率(不管是在速度、内存、资源使用，还是两者的结合)，实际上会产生预期的好处，而不会带来其他的不足，实际上，它们不会真正损害他们所追求的领域的效率( .NET世界的一个经典就是人们，往往出于控制的情感欲望，把GC视为他们的敌人，并努力“提高”垃圾收集的效率-也许95%或更多的时间)。

这太早了，因为太早了。

Answer 3

过早的优化通常是指在提高性能的同时降低代码的可读性。当我问它到底是什么的时候，我最好把它描述为“当你看到它的时候你就知道了”，这可能没什么用。

我可以想到一些临时的例子：

1. 在for-循环中使用位损坏来增加计数器。
2. 创建一个大型函数，而不是许多较小的函数，以避免函数调用开销。
3. 设置所有公共设置，以避免变异器和访问器的开销。
4. 在数据对象中创建一个常用字符串列表，这样它们就不需要不断地重新分配(字符串池任何人？)
5. 编写自己的集合，它反映现有集合中的功能，以避免边界检查的开销。

我肯定我见过更多，但是，你知道。