性能总是很重要吗？

Question

由于我是一名独立开发者，我必须考虑我正在开发的系统的各个方面。最近我一直在考虑我的两个网站的性能，以及改进它的方法。像StackOverflow这样的网站宣称，“性能是一种功能”。然而，“过早优化是所有邪恶的根源”，我的客户都没有抱怨网站的表现。

我的问题是，表现总是很重要吗？性能应该始终是一个功能吗？

注意：我不认为这个问题与this one相同，因为那张海报在询问何时考虑表现，而我问的问题的答案是否总是如此，如果是的话为什么我也不认为这个问题应该是CW，因为我相信这个答案有一个答案和推理。

Answer 1

充足的表现始终很重要。

绝对最快的表现几乎不重要。

始终值得关注性能并了解您正在做的任何离谱非优化（特别是在设计/架构层面），但这与微优化不同每一行代码。

Answer 2

表现！=优化。

性能确实是一项功能，但过早优化会花费您的时间，并且不会产生与优化需要优化的部件时相同的结果。在你真正分析某些内容之前，你无法真正知道哪些部分需要优化。

性能是您的客户不会告诉您它是否缺失的功能，除非它真的非常缓慢且他们被迫使用您的产品。现有客户最终可能会报告，但如果需要性能，新客户将无需担心。

您需要了解所需的性能，并将其作为一项要求进行制定。然后，你必须满足自己的要求。

Answer 3

牢记性能 但考虑到你的情况，在前面花费太多时间是不明智的。

性能很重要，但通常很难知道瓶颈在哪里。因此，我建议您在完成某项工作后，计划花一些时间来使用此功能。

因此，您需要设置对您和您的客户都很重要的指标。保持并分析这些测量。然后估算每个实现的时间和长度。现在你可以瞄准为你的降压/时间获得更多爆炸。

如果是网络，最好使用Firebug + yslow 和/或Google网页速度来记录您的网页尺寸和效果。再次，知道什么适用于像你这样的小网站和仅适用于雅虎和谷歌的东西。

Answer 4

这种“邪恶的根源”几乎总是被滥用和误解。

设计您的应用程序以表现良好可以通过良好的设计来完成。良好的设计！=过早的优化，并且完全写出废话代码并且在设计上做得更好，作为一种“邪恶的”浪费是完全荒谬的。现在，我在这里并没有特别谈论你......但是我看到人们这么做了。

通常保存您有时间做好设计工作。如果你强调这一点，你就会变得更好......并且在编写从一开始就表现良好的系统时会越来越快。

了解在某些情况下哪种结构和访问方法最有效是关键。

当然，如果您的应用程序变得非常庞大或者有疯狂的速度要求，您可能会发现自己正在进行欺骗性优化，使您的代码更难或更难维护......在您需要之前做这些事情是错误的到。

但这绝对是 NOT 与努力理解和使用正确的算法或数据模式或其他任何事情相同的事情。

如果可以忍受，您的用户可能不会抱怨性能不佳。他们甚至可能不知道可以更快。作为主要驱动因素的投诉是一种糟糕的经营方式。当然，你需要解决你收到的投诉......但缺乏这些投诉并不意味着没有问题。您正在考虑提高性能这一事实在某种程度上是一个指标。这只是一时兴起，还是你告诉你应该更好的一部分？你为什么考虑改进它？

不要疯狂做不必要的事情。

Answer 5

  

杰克逊的优化规则：

     

规则1.不要这样做。

     

规则2（仅限专家）。不要这样做   然而，直到你有一个   完全清晰，未经优化   溶液

     

M。 A.杰克逊

摘自Code Complete第2版。

Answer 6

对一般性问题给出一般性答案：

首先让工作，然后使其正确，然后制作它快速。

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

这对“过早优化是一切罪恶的根源”提出了更具建设性的观点。

因此，为了平行Jon Skeet的答案，充分的表现（作为使某些事情发挥作用，并使其成功的一部分）始终是重要的。即便如此，它通常可以在其他功能之后解决。

Answer 7

Jon Skeets'足够'指甲它，附加规定对于你不知道什么是足够的图书馆，所以最好安全地犯错。

这是你不能错过的众多赌注之一，但你的应用程序的质量在很大程度上取决于最薄弱的环节。

在某种意义上，性能绝对是重要的 - 也许不是你的意思：即在开发的所有阶段。

在Big O表示法中，parantheses内部的内容在很大程度上取决于设计 - 包括组件隔离和数据存储。算法的选择通常只会是最佳/最坏情况行为（除非你从明确的不合格算法开始）。代码优化将主要影响常数因子 - 也不应忽略。

但是对于代码的所有方面都是如此：在任何阶段，你都有很好的机会在任何方面都失败 - 稳定性，可维护性，兼容性等。性能需要平衡，以免留下任何方面。

Answer 8

在大多数应用程序中，90％或更多的执行时间花费在代码的10％或更少。通常，优化其他代码几乎没有用这些10％。

Answer 9

性能的重要性在很大程度上取决于您的工作。

例如，如果您编写的库可以在任何环境中使用，那么这几乎不会有太多的性能。在某些环境中，10％的性能优势可能是库的主要特性。

如果你，OTOH，写一个应用程序，它总是有一个足够快的点。用户既不会意识也不关心按下的按钮是否会在0.05或0.2秒内反应 - 即使这是4倍。

然而，获得更快的代码工作总是更容易获得更快的代码。

Answer 10

只有在开发性能改进所花费的时间少于为用户保存的总时间时，性能才是最重要的。

结果是，如果你正在为数百万人开发一些东西......是的，节省时间是很重要的。如果你正在编写一个供你自己使用的工具......那么节省一分钟甚至一小时或更长的时间可能会更麻烦。

（这显然不是一成不变的规则......无论需要多长的开发时间，有时候性能才真正至关重要）

Answer 11

应该有一切平衡。例如，成本（或开发时间）与性能相比。更高的性能=更多的成本。如果正在构建的系统的要求是高性能，则成本应该无关紧要，但如果成本是一个因素，那么您可以在合理范围内进行优化。过了一段时间，您的投资回报会受到影响，因为更多的表现并不能带来更多的回报。

Answer 12

性能的重要性是恕我直言与您的问题集高度相关。如果您正在创建一个期望负载繁重且服务器端处理很多的站点，那么您可能希望将更多时间用于性能（否则您的站点可能最终无法使用）。但是，对于大多数应用程序而言，优化网站性能的时间并不会有所回报 - 用户不会注意到差异。

所以我猜它可以分解为：

用户是否会注意到这些改进？ 这种改进与竞争网站相比如何？

如果用户会注意到并且改进足以使您与竞争对手区分开来 - 性能是一个重要特征 - 否则不是那么多。 （关于某一点 - 我不建议完全忽略它 - 你不希望你的网站毕竟是乌龟）。

Answer 13

没有。足够快就足够了。

但是，客户关于“足够快”的想法应该胜过自己的想法并不一定正确。如果你认为它足够快而且你的客户不是，那么你需要将他们的想法提供给他们。但是，如果你的客户认为它足够快而且你没有，那么你应该认真考虑与你的意见一致，而不是他们的意见（因为你可能更了解更广泛世界的绩效标准）。

Answer 14

否。表现并不重要。

缺乏绩效非常重要。

Answer 15

性能是从一开始就要设计的，而不是最后的设计。在过去的15年里，我一直从事性能工程领域的工作，而我工作的大多数项目失败的原因是缺乏对性能的要求。一些帖子已经注意到“足够快”作为观察以及您的期望是否与您的客户的期望相匹配，但是当您遇到客户，架构团队，平台工程团队，功能测试团队，您的情况时，您的情况如何？绩效测试团队和您的运营团队对绩效都抱有不同的期望，其中没有一个人致力于追求和衡量。坏魔法是肯定的。

抓住客户的期望。让他们达到一个特定的，客观的，可衡量的要求，您可以在软件生产的每个阶段进行评估。期望可能不一致，您的应用程序/代码的一部分需要比其他部分更快，每个客户也不会对可接受的内容抱有相同的期望。掌握这些信息将迫使您面对过去可能忽略的设计和实施决策，这将导致产品更符合您的客户期望。