何时优化过早？
正如Knuth所说，
我们应该忘记小效率，大约97％的时间：过早优化是所有邪恶的根源。
这是Stack Overflow经常遇到的问题，例如“哪个是最有效的循环机制”，“SQL优化技术？”等问题。 （等等）。 这些优化技巧问题的标准答案是分析代码并确定它是否是一个问题，如果不是，那么您的新技术就不需要了。
我的问题是，如果一种特定的技术不同，但不是特别模糊或混淆，那么这是否真的被认为是过早的优化？
这是Randall Hyde撰写的一篇名为“过早优化的谬误”的相关文章。
Don Knuth开始了文字编程运动，因为他相信计算机代码最重要的功能是将程序员的意图传达给读者 。 任何使您的代码难以在性能名称中理解的编码习惯是不成熟的优化。
以优化名义引进的某些成语已经变得如此受欢迎，以至于每个人都了解它们，并且它们已经成为预期，并不是不成熟的。 例子包括
在C中使用指针算术而不是数组符号 ，包括使用这样的成语
for (p = q; p < lim; p++)
将全局变量重新绑定到 Lua中的局部变量 ，如in
local table, io, string, math
= table, io, string, math
除了这些成语之外，你还可以快捷地处理你的危险 。
除非，所有优化都是不成熟的
一个节目太慢了 （很多人都忘记了这部分）。
你有一个测量 （简介或类似），表明优化可以改善事情 。
（也可以对内存进行优化。）
直接回答问题：
编辑 ：作为对评论的回应， 使用快速排序代替插入排序等更简单的算法是另一个每个人都能理解和期待的成语例子。 （尽管如果你编写自己的排序例程而不是使用库排序例程，人们希望你有一个很好的理由。）
恕我直言，90％的优化应该发生在设计阶段，基于percieved目前，更重要的是，未来的要求。 如果因为应用程序没有按照所需的负载进行扩展而不得不取消所需的负载，那么您必须取出一个分析器，否则IMO将浪费大量时间和精力，但未能纠正问题。
通常情况下，唯一有价值的优化是那些在速度方面获得数量级性能提升的存储或带宽乘法器。 这些类型的优化通常与算法选择和存储策略相关，并且极难反转到现有代码中。 它们可能会影响您实施系统的语言决策。
因此，我的建议是根据您的要求尽早进行优化，而不是根据您的代码进行优化，并着眼于可能延长应用程序的寿命。
如果你还没有分析，那还为时过早。
链接地址: http://www.djcxy.com/p/1027.html