什么时候优化过早？

Question

我看到这个术语使用了很多,但我觉得大多数人都是出于懒惰或无知而使用它.例如,我正在阅读这篇文章:

他谈到他的决定,他为实现他的应用程序所需的类型.

如果是我,谈论这些我们需要编写的代码,其他程序员会想到:

或两者.

并建议只是实施它,而不是担心这些,直到它们成为一个问题.

哪个更优惠？

在完成任何实施之前,如何区分性能关键应用程序的过早优化与知情决策？

Answer 1

在以下情况下优化为时过早

您的应用程序没有做任何时间关键的事情.(这意味着,如果你正在编写一个程序,在一个文件中添加500个数字,"优化"这个词甚至不应该流入你的大脑,因为它所做的只是浪费你的时间.)
你在装配以外的事情上做了一些时间关键的事情,并且仍然担心是否i++; i++;更快还是i += 2......如果它真的那么重要,你就会在装配工作而不是浪费时间担心这一点.(即便如此,这个特殊的例子很可能无关紧要.)
你有一种预感,一件事可能比另一件事快一点,但你需要查一查.例如,如果有什么东西在猜你是否StopWatch更快,或者Environment.TickCount是过早的优化,那么如果差异更大,你可能会更加确定并且不需要查找它.

如果您猜测某些内容可能会很慢,但您不太确定,只需//NOTE: Performance?发表评论,如果您以后遇到瓶颈,请在代码中检查这些位置.我个人并不担心不太明显的优化; 如果需要的话,我稍后会使用一个分析器.

另一种技术:

我只是运行我的程序,用调试器随机打入它,看看它停在哪里 - 无论它停在哪里都可能成为瓶颈,它停在那里的次数越多,瓶颈就越严重.它几乎像魔术一样工作.:)

Answer 2

过早优化是指在您知道有必要进行这种权衡之前，以牺牲代码的其他一些积极属性（例如可读性）为代价来进行性能优化。

通常，过早的优化是在开发过程中进行的，没有使用任何分析工具来查找代码中的瓶颈。在许多情况下，优化会使代码更难维护，有时还会增加开发时间，从而增加软件成本。更糟糕的是......一些过早的优化根本不会使代码变得更快，在某些情况下甚至可能使代码比以前慢。