我看到这个词用得很多，但我觉得大多数人使用它是出于懒惰或无知。例如，我正在读这篇文章：
http://blogs.msdn.com/b/ricom/archive/2006/09/07/745085.aspx
他在其中谈到了他为实现应用程序所需的类型而做出的决定。
如果是我，在我们需要编写的代码中谈论这些，其他程序员可能会认为：
- 当什么都没有的时候，我想得太多，因此过早地优化。
- 在没有遇到速度减慢或性能问题的情况下，过度考虑无关紧要的细节。
or both.
并建议只实施它，不要担心这些，直到它们成为问题。
哪个更优惠？
在完成任何实施之前，如何区分性能关键型应用程序的过早优化与明智决策？
如果出现以下情况，优化就为时过早：
您的应用程序没有执行任何对时间要求严格的操作。 （这意味着，如果您正在编写一个将文件中的 500 个数字相加的程序，那么“优化”这个词根本不应该出现在您的大脑中，因为它只会浪费您的时间。）
您正在做一些除装配之外的时间紧迫的事情，并且仍然担心是否i++; i++;更快或i += 2... 如果它是really至关重要的是，您将在装配中工作，而不是浪费时间担心这个。 （即便如此，这个特定的例子很可能并不重要。）
你有一个hunch一件事可能比另一件事快一点，但你需要查一下。例如，如果有什么事情困扰着你是否StopWatch更快或Environment.TickCount，这是不成熟的优化，因为如果差异更大，您可能会更加确定并且不需要查找它。
如果您猜测某件事可能会很慢但又不太确定，只需输入//NOTE: Performance?注释，如果以后遇到瓶颈，请检查代码中的此类位置。我个人并不担心不太明显的优化；如果需要的话，我稍后会使用分析器。
另一种技术：
我只是运行我的程序，用调试器随机中断它，然后查看它在哪里停止——无论它停止在哪里，都可能是瓶颈，而且停在那里的次数越多，瓶颈就越严重。它的作用几乎就像魔术一样。 :)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
