短语“ 过早优化 ” 似乎是当今的流行语。出于某种原因,尤其是iphone程序员似乎将避免过早的优化视为积极的目标,而不是单纯地避免分散注意力的自然结果。问题是,该术语开始越来越多地应用于完全不合适的案例。
例如,我已经看到越来越多的人说不用担心算法的复杂性,因为那是过早的优化。坦率地说,我认为这只是懒惰,对有纪律的计算机科学而言是令人震惊的。
但是我想到,也许考虑算法的复杂性和性能正在沿着装配循环展开的方式发展,而现在认为其他不必要的优化技术也是如此。
你怎么看?我们现在是否在确定O(n ^ n)和O(n!)复杂度算法之间是不相关的?O(n)vs O(n * n)呢?
您如何看待“过早优化”?您使用什么实际规则有意识或无意识地避免使用它?
编辑
我知道我的描述有点笼统,但是我对人们用来避免“过早优化”的 特定,实用规则 或最佳做法感兴趣, 特别是在iphone平台上 。
要回答这个问题,您首先需要回答“什么是过早优化”。由于该定义显然相差很大,因此任何有意义的答案都需要作者定义该术语。这就是为什么我真的不认为这是CW问题。同样,如果人们不同意,我会更改它。
什么是过早的优化?
过早优化是在知道是否值得进行优化之前(通常是为了提高性能)优化代码的过程。过早优化的一个示例是在对代码进行概要分析之前先对其进行优化,以找出性能瓶颈所在的位置。过早优化的另一个极端示例是在运行程序并确定其运行速度太慢之前进行优化。
我们现在是否在确定O(n ^ n)和O(n!)复杂度算法之间是不相关的?O(n)vs O(n * n)呢?
这取决于n的大小以及代码被调用的频率。
如果n始终小于5,则渐近性能无关紧要。在这种情况下,常数的大小将更为重要。对于小n,简单的O(n * n)算法可以击败更复杂的O(n log n)算法。或可测量的差异可能很小,以至无所谓。
我仍然认为,有太多人花时间来优化90%无关紧要的代码,而不是10%的重要时间。没有人关心某些代码是否需要10毫秒而不是1毫秒(如果几乎从未调用过该代码)。有时候,即使您知道算法复杂性不是最佳的,但简单地做一些可行的事情并继续前进是一个不错的选择。
您花费很少的时间来优化很少使用的代码,比添加人们真正想要的功能所花费的时间少一小时。