过早优化的实践规则 [英] Practical rules for premature optimization

问题描述

似乎短语过早优化是当天的嗡嗡声。由于某些原因，iPhone程序员特别似乎认为避免过早优化作为主动的目标，而不是简单避免分心的自然结果。问题是，这个术语开始越来越多地被应用于完全不适当的情况。

It seems that the phrase "Premature Optimization" is the buzz-word of the day. For some reason, iphone programmers in particular seem to think of avoiding premature optimization as a pro-active goal, rather than the natural result of simply avoiding distraction. The problem is, the term is beginning to be applied more and more to cases that are completely inappropriate.

例如，我看到越来越多的人说不担心算法的复杂性，因为这是过早的优化（例如帮助排序NSArray跨两个属性（NSSortDescriptor？））。坦白说，我认为这只是懒惰，而且令人震惊的是计算机科学。

For example, I've seen a growing number of people say not to worry about the complexity of an algorithm, because that's premature optimization (eg Help sorting an NSArray across two properties (with NSSortDescriptor?)). Frankly, I think this is just laziness, and appalling to disciplined computer science.

但是，对我来说，也许考虑到算法的复杂性和性能正在走向组装循环展开，以及其他优化技术，现在被认为是不必要的。

But it has occurred to me that maybe considering the complexity and performance of algorithms is going the way of assembly loop unrolling, and other optimization techniques that are now considered unnecessary.

你觉得怎么样？现在我们现在在O（n ^ n）和O（n！）复杂度算法之间决定是无关紧要的吗？ O（n）vs O（n * n）呢？

What do you think? Are we at the point now where deciding between an O(n^n) and O(n!) complexity algorithm is irrelevant? What about O(n) vs O(n*n)?

你认为过早优化是什么？你有什么实际的规则有意识或无意识地避免使用？

What do you consider "premature optimization"? What practical rules do you use to consciously or unconsciously avoid it?

编辑

我知道我的描述有点笼统，但我对具体的实用规则感兴趣或人们用来避免成熟前优化的最佳实践，特别是在iphone平台上 / strong>。

I know my description is a bit general, but I'm interested in specific, practical rules or best practices people use to avoid "pre-mature optimization", particularly on the iphone platform.

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

Answering this requires you to first answer the question of "what is pre-mature optimization?". Since that definition clearly varies so greatly, any meaningful answer requires the author to define the term. That's why I don't really think this is a CW question. Again, if people disagree, I'll change it.

推荐答案

什么是过早优化？ / p>

What is premature optimization?

过早优化是在知道是否值得这样做之前优化代码（通常用于性能）的过程。过早优化的一个例子是优化代码，然后再对其进行剖析，以了解性能瓶颈在哪里。在您运行程序并确定运行速度太慢之前，过早优化的一个更加极端的例子就是优化。

Premature optimization is the process of optimizing your code (usually for performance) before you know whether or not it is worthwhile to do so. An example of premature optimization is optimizing the code before you have profiled it to find out where the performance bottleneck is. An even more extreme example of premature optimization is optimizing before you have run your program and established that it is running too slowly.

现在在O（n ^ n）和O（n！）复杂度算法之间决定是不相关的点？那么O（n）对O（n * n）呢？

Are we at the point now where deciding between an O(n^n) and O(n!) complexity algorithm is irrelevant? What about O(n) vs O(n*n)?

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

It depends on the size of n and how often your code will get called.

如果n总是小于5，则渐近性能是无关紧要的。在这种情况下，常数的大小将更为重要。一个简单的O（n * n）算法可以击败较小的n的更复杂的O（n log n）算法。或者可衡量的差异可能很小，这并不重要。

If n is always less than 5 then the asymptotic performance is irrelevant. In this case the size of the constants will matter more. A simple O(n * n) algorithm could beat a more complicated O(n log n) algorithm for small n. Or the measurable difference could be so small that it doesn't matter.

我仍然认为有太多人花时间优化90％的代码，不重要，而不是10％。没有人关心，如果代码几乎没有被调用，代码需要10ms而不是1ms。有时候，只是做一些简单的工作和移动是一个不错的选择，即使你知道算法的复杂性不是最优的。

I still think that there are too many people that spend time optimizing the 90% of code that doesn't matter instead of the 10% that does. No-one cares if some code takes 10ms instead of 1ms if that code is hardly ever called. There are times when just doing something simple that works and moving on is a good choice, even though you know that the algorithmic complexity is not optimal.

每小时你花费优化很少称为代码是一小时，您可以花费增加人们实际想要的功能。

Every hour you spend optimizing rarely called code is one hour less that you can spend on adding features people actually want.

这篇关于过早优化的实践规则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！