何时优化过早？
我看到这个词用了很多，但我觉得大多数人都是懒惰或无知的人使用它。 例如，我正在阅读这篇文章：
http://blogs.msdn.com/b/ricom/archive/2006/09/07/745085.aspx
他在那里谈论他为实现他应用程序所需的类型而作出的决定。
如果是我，谈论这些我们需要编写的代码，其他程序员会认为：
或两者。
并建议实施它，而不是担心这些，直到他们成为一个问题。
哪个更优惠？
如何在执行任何实现之前区分过早优化和性能关键应用程序的知情决策？
如果：优化过早
你的应用程序没有做任何时间关键的事情。 （也就是说，如果你正在编写一个在一个文件中加上500个数字的程序，“优化”这个词甚至不应该流入你的大脑，因为它只会浪费你的时间。）
你对汇编以外的东西做了一些时间关键的事情，并且仍然担心i++; i++; i++; i++; 是更快还是i += 2 ...如果真的那么重要，你会在汇编中工作，而不是浪费时间担心这个。 （即使这样，这个特例也很重要。）
你有预感，有一件事可能比另一件事快一些，但你需要查看它。 例如，如果有些事情是关于StopWatch速度更快还是Environment.TickCount ，那么这是过早的优化，因为如果差异更大，您可能会更确定并且不需要查看它。
如果你猜测某些东西可能会很慢，但你不太确定，那么只需放一个//NOTE: Performance? 评论，如果你后来遇到瓶颈，请在代码中检查这些地方。 我个人不担心优化不太明显; 如果需要，我稍后会使用一个分析器。
另一种技术：
我只是运行我的程序，用调试器随机分解它，并查看它停止的地方 - 停止的任何地方都可能是瓶颈，而且越频繁地停在那里，瓶颈就越严重。 它的作用几乎像魔术一样。 :)
这个谚语并没有（我相信）是指在创建好的设计中内置的优化。 它指的是专门针对表演的任务，否则将不会进行。
根据共同的看法，这种优化不会“过早”，直到证明无辜为止是有罪的。
优化是使现有代码更有效运行的过程（更快的速度和/或更少的资源使用）
如果程序员没有证明它是必要的，那么所有的优化都是不成熟的。 （例如，通过运行代码来确定它是否在可接受的时间范围内实现了正确的结果，这可能非常简单，只要运行它即可“查看”其运行速度是否足够快，或者在分析器下运行以更仔细地进行分析） 。
有几个阶段可以很好地编程：
1）设计解决方案并选择一个好的，高效的算法 。
2）以可维护，编码良好的方式实施解决方案。
3）测试解决方案，看它是否满足您对速度，内存使用等方面的要求（例如“当用户点击”保存“时，是否需要少于1秒？”如果需要0.3秒，吨需要花费一个星期的时间来优化它，让时间降到0.2秒）
4） 如果不符合要求，请考虑原因。 在大多数情况下，这意味着如果您更好地理解问题，则会转到步骤（1）以找到更好的算法。 （编写快速原型通常是便宜地探索这种方法的好方法）
5） 如果它仍然不符合要求，请考虑可能有助于加速运行时间的优化（例如，查找表，缓存等）。 为了推动这个过程， 分析通常是一个重要的工具，可以帮助您找到代码中的瓶颈和无效情况，因此您可以在代码上花费最多时间。
我应该指出，一位经验丰富的程序员从事一个相当熟悉的问题，可能能够在思维上跳过第一步，然后应用一种模式，而不是每次都在物理上经历这个过程，但这只是一个简捷通过经验获得
因此，经验丰富的程序员会自动将其构建到自己的代码中进行许多“优化”。 这些不是“过早的优化”，而是“常识效率模式”。 这些模式快速且易于实现，但大大提高了代码的效率，并且您不需要执行任何特殊的时间测试来确定它们是否会有好处：
例如，我刚刚在我们的项目中替换了一段旧代码。 我的新代码没有以任何方式“优化”，但（与原始实现不同），它的编写效率非常高。 结果：矿井运行速度提高25倍 - 只是不浪费。 我可以优化它以使其更快吗？ 是的，我可以轻松获得另一个2倍加速。 我会优化我的代码以使其更快吗？ 没有 - 5倍的速度提升已经足够了，我已经达到了25倍。 此时的进一步工作只会浪费宝贵的编程时间。 （但是如果需求发生变化，我可以在将来重新访问代码）
最后，最后一点：您正在工作的地区决定了您必须满足的条款。 如果您正在为实时嵌入式控制器编写游戏或代码的图形引擎，您可能会发现自己正在进行大量优化。 如果您正在编写桌面应用程序（如记事本），则只要不过度浪费，您可能永远不需要优化任何内容。
链接地址: http://www.djcxy.com/p/39635.html