过早优化的实用规则

Question

似乎" 过早优化 " 这个短语是当时的热门话题.出于某种原因,特别是iphone程序员似乎认为避免过早优化是一个积极的目标,而不是简单地避免分心的自然结果.问题是,该术语开始越来越多地应用于完全不合适的案例.

例如,我看到越来越多的人说不要担心算法的复杂性,因为那是不成熟的优化(例如,帮助在两个属性(使用NSSortDescriptor？)中排序NSArray).坦率地说,我认为这只是懒惰,并且对纪律严明的计算机科学感到骇人听闻.

但是我想到,可能考虑到算法的复杂性和性能正在推动汇编循环展开的方式,以及其他现在认为不必要的优化技术.

你怎么看？我们现在处于决定O(n ^ n)和O(n!)复杂度算法无关的地步吗？那么O(n)vs O(n*n)呢？

您认为"过早优化"是什么？您有意或无意地避免使用哪些实用规则？

编辑

我知道我的描述有点笼统,但我对人们用来避免"预成熟优化"的具体,实用规则或最佳实践感兴趣,尤其是在iphone平台上.

回答这个问题需要您首先回答"什么是预成熟优化？"的问题.由于该定义明显变化很大,任何有意义的答案都要求作者定​​义该术语.这就是为什么我不认为这是一个CW问题.再说一次,如果人们不同意,我会改变它.

Answer 1

什么是过早优化？

过早优化是在您知道是否值得这样做之前优化代码(通常用于性能)的过程.过早优化的一个示例是在对代码进行分析之前优化代码,以找出性能瓶颈所在.一个更为极端的过早优化示例是在运行程序并确定运行速度太慢之前进行优化.

我们现在处于决定O(n ^ n)和O(n!)复杂度算法无关的地步吗？那么O(n)vs O(n*n)呢？

这取决于n的大小以及调用代码的频率.

如果n总是小于5,那么渐近性能是无关紧要的.在这种情况下,常量的大小将更重要.对于小n,简单的O(n*n)算法可以击败更复杂的O(n log n)算法.或者可衡量的差异可能很小,无关紧要.

我仍然认为有太多的人花时间优化90%的代码而不是10%的代码.如果某些代码几乎没有被调用,那么没有人会关心一些代码需要10ms而不是1ms.有时候做一些简单的工作和继续是一个很好的选择,即使你知道算法的复杂性不是最优的.

您花在优化很少调用的代码上的每小时花费的时间少于您添加人们实际想要的功能所花费的时间.

Answer 2

我的投票支持大多数人优化他们认为的弱点,但他们没有描述.

所以,不管你如何知道的算法也不管你是如何写得好你的代码,你不知道还有什么正在发生的模块之外.您调用的API在幕后做了什么？您是否总能保证ops的特定顺序是最快的？

这就是早熟优化的含义.您认为任何未通过分析器或其他权威工具进行严格测试的优化(ops的时钟周期并不是坏事,但它只能告诉您性能特征〜实际调用比定时更重要,通常),是一个不成熟的优化.

@k_b说它远远高于我,这也是我说的.做对,简单,然后分析,然后调整.根据需要重复.

Answer 3

优先顺序:1.必须工作 2.必须可维护 3.必须具有机器效率

那是我第一次编程课程的第一周.在1982年.

"优先级过低"是优先级3在优先级1或优先级2之前被考虑的任何时间.

请注意,现代编程技术(抽象和接口)旨在使此优先级更容易.

在一个灰色区域:在最初的设计中,你就必须检查你的解决方案是不是天生几近极限的慢.否则,在您至少拥有一些正常工作的代码之前,请不要担心性能.

Answer 4

对于某些人来说,优化是编写代码的乐趣的一部分,过早或不成熟.我喜欢优化,并为了易读性而克制自己.不优化的建议是喜欢优化的人.

特别是iphone程序员似乎认为避免过早优化是一个积极主动的目标

大多数iPhone代码都与UI相关.没有太多需要优化.不需要选择会导致性能不佳的糟糕设计,但是一旦开始编写好的设计,就不需要进行优化.因此,在这种情况下,避免优化是一个合理的目标.