在历史上，很少有语句对软件开发项目造成比“过早优化是万恶之源”更大的伤害。首先，让我们不要玷污托尼·霍尔的好名声。这句话来自唐纳德·克努斯，而缺少的上下文是至关重要的。在他的1974年论文《使用goto语句的结构化编程》中写道：“程序员们浪费大量时间去思考或担心他们程序中非关键部分的速度，这些效率尝试在考虑调试和维护时实际上产生了强烈的负面影响。我们应该忘记小的效率，大约97%的时间里：过早优化是万恶之源。然而，在那关键的3%中，我们不应该错过机会。” 他当时是在谈论在C语言中使用goto语句。他是在说为了微小的优化而让软件更难理解。他假设（错误地）我们会尊重软件运行的机器。…
源讨论罗伯·派克的编程五规则原帖 448 条评论 · 导入时统计把你的经验，加入这段讨论。
> 缺少的上下文是至关重要的。 哦，是的，我建议所有使用这个短语的人都去阅读论文的其余部分，看看Knuth认为合理的优化类型。例如，优化快速排序中的内存访问。
完整原文说实话，这是较少被误用的引用之一，我从中学到的比造成的伤害更多。 像你一样，我见过很多人写出很多慢速代码，但大多是那些很难写出更快代码的人，而这些代码还更不容易出错。 我讨厌慢速软件，但比起错误的软件，我宁愿选择慢速软件。此外，通常修复性能问题比修复错误行为更容易，尤其是当错误已经产生了我们可能无法访问的数据时。但更甚的是，当危害已经影响到现实世界时。
完整原文> 多代程序员现在都被培养成认为残酷的低效、臃肿和慢速软件是完全可以接受的。计算机可以被强迫执行的样板代码和间接操作的数量是没有上限的。这些天才们不断产生的晶体抽象也没有顶点。JVM启动所花的时间再长也没关系。 我认为这是由于人们进行了过早的优化！如果人们认真对待这句话，他们就不会倾向于增加样板代码和间接操作的数量。
完整原文我明白你的意思，朋友！ 当你在谷歌看到Java的问题时，我在Python中也看到了类似的问题。 太多的间接层次。天哪！太多不必要的超类和混入类！如果你的间接层次超过了人类思维所能理解的深度，你就无法理解代码。 还有一种观点认为列表推导式在某种程度上是更优的，它们会扩展成10行的难以阅读的代码，而嵌套的for循环会更易读且同样快速，但因为列表推导式被神化了，没有人会在其自然的可读性极限处停止。结果就像在阅读你刚刚经历的冗长句子一样。
完整原文在你看到分析结果之前忽略优化机会，只有在你真的进行了分析时才有效！ 分析性能从未像编译、检查或单元测试那样成为大多数开发者的常规流程的一部分。 有多少真正的CI/CD流程会生成火焰图并将其与测试结果一起输出？
完整原文另一个来自我个人经验的建议：在第三次需要某样东西时再应用DRY原则（不要重复自己）。换句话说：你允许在两个不同的地方复制粘贴相同的代码。 我们经常在只需要一两个地方使用某段逻辑时就将其泛化，这使我们在它们不可避免地开始出现差异时变得更加复杂。而且我们实际上可能不会需要它超过两次。 过早泛化是初级开发者和有经验的开发者之间最常见的区别。
完整原文嗯，我一直以来对这句话的理解非常不同，重点在于“过早”……不是说“不要优化”，而是说“在你理解问题之前不要优化”……或者像我一位计算机科学教授说的：“先让它运行起来，然后再让它运行得更快”……
完整原文我也通过一个所谓的并发优先队列学到了这一点，它在持有整个锁的情况下执行了二次时间复杂度的工作。我被告知“过早优化是万恶之源”。 抱歉，伙计们，但这只是做出愚蠢选择的借口。过早的_微观优化才是万恶之源。 编辑：不过这对我后来开始从事浏览器性能工作很有帮助！
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。