优化有多重要？

昨天我与老板讨论了在构建软件时优化的正确作用.从本质上讲,他的立场是优化需要成为整个开发过程中的主要关注点.

我的观点是你需要在开发过程中做出正确的算法决策,但你永远不应该在开发过程中计算周期.事实上,我对此感到非常强烈,我不得不离开谈话.我在"优化"的名义下看到了太多错误的编程决策,而且过多的错误代码以"这种方式更快"为借口辩护.

StackOverflow.com社区的想法是什么？

"我们应该忘记效率低下,大约97%的时间说:过早的优化是所有邪恶的根源.但我们不应该把这个关键的3%的机会放弃."

我认为过早的优化引用被太多使用,以避免考虑有关应用程序运行情况的难题.我保证用户希望您考虑如何设计它,以便尽可能快地运行.

这并不是说你应该对所有东西进行计时,但设计阶段是最容易优化的地方,而不是花费大量时间.

经常有几种方法可以做任何事情,你应该在设计阶段挑选其中一个最有可能执行的最好(如果它原来是一个时代,当它是不是最好的,然后再优化).这应该胜过需要易于阅读的代码.

如果您没有在设计阶段考虑性能,那么您将无法拥有设计良好的系统.这并不意味着它应该是唯一的问题(虽然在数据库中我将​​其评为重要性的第3位,就在数据完整性和安全性之后),但是试图修复一个系统,其中整个过程中使用性能较差的技术因为开发人员以为他们更容易理解是一场噩梦.作为这样一个系统的用户,每次你想要从一个屏幕移动到另一个屏幕时你必须等待几分钟是一场噩梦(开发人员应该每天花一整天时间,至少一周,使用他们的系统!)给每个人坚持设计糟糕的系统.它的设计成本要低于以后修复的成本,并且考虑到性能对于正确设计至关重要.

我工作的地方在原单开发喝关于过早优化的koolaid和所做的一切他们认为是最简单的(但在几乎所有情况下是从性能的角度来看是错误的选择)的方式.现在我们的规模是三年前的10倍,每个网站上的每个屏幕都需要30秒左右才能加载(或更糟糕的时候),因此我们正在失去客户.但改变它会太硬,因为在基地,他们设计了数据库,而不考虑它是如何执行和重新设计数据的许多许多GB数据库到一个新的结构方式太耗时和昂贵.如果它从一开始就被设计为执行,那么对于客户来说,它将更容易维护和更快.我们不是在谈论需要进行性能调整这里的前10名最慢的查询,我们谈论的是一个整体结构需要一个急剧变化(一个将几乎影响对系统中的每个查询)表现良好的事实.

是的,不要做微观优化,直到你知道,但请做宏观的东西.在提交路径之前,请考虑这是否是最好的方法.当基于集合的语句执行时,不要编写游标来命中具有数百万条记录的表.不要试图拥有尽可能少的表,因为当表存储不同的项目(例如人,地点和车辆)时,似乎是一个更优雅的解决方案,导致每个查询都命中同一个表并导致每次删除检查那些永远不会有该类型实体记录的各种外键表(从我们数据库的主表中删除一条记录需要几分钟,当导入中出现问题时,这是一个真正的乐趣(坏数据)通常来自客户)我们必须删除200,000让我告诉你).

优化几乎是同义反复的权衡:以其他东西为代价获得运行时效率(可读性,可维护性,灵活性,编译时间等).因此,除非你知道什么是权衡以及为什么值得这样做,否则这绝不是一个好主意.

更糟糕的是,考虑"我如何快速做X"可能会让人分心.在这个方向上的大量能量很容易导致你对方法Y的误解更好(并且通常更快 - 这就是"优化"可以使你的代码变慢的方式).特别是如果你从一开始就在一个大项目上做太多这样的事情,那就代表了很多动力.如果你无法克服这种势头,你很容易陷入糟糕的设计,因为你没有时间重组它.这种方式就是龙

你的老板可能会想到的更多是通过不恰当的表示和算法编写错误代码的问题.它与优化并不是一回事,但是一种你不关注适当的数据结构等的方法会导致代码库在任何地方都很慢,而且(就像上面的"锁定"一样)需要英雄的努力来解决.

总的来说,过早的优化确实是一个可怕的想法.特别是当你最终得到一个复杂的,精心调整的,有文档记录的(因为这是你能理解它的唯一方法)时,你最终还是没有使用这些代码.而这甚至没有涉及"优化"时经常引入的微妙错误的问题

[编辑:pshaw,当然Knuth引用很好地封装了这个.这就是我输入太多的东西]

全程工程师,最终优化.