Performance 我是否总是要考虑性能？

我来自一个DBA的世界，性能一直是一个困扰。我转向发展，我一直在不断地思考绩效

读下去，有时似乎表现并不重要。例如，对于hibernate（或任何其他ORM）上的福音传道者

作为一名开发人员，我什么时候需要考虑性能，什么时候不需要考虑性能？

这句话可能适用（“我们应该忘记小效率，比如说97%的时间：过早优化是万恶之源”）

当你开车时，你是否经常有意识地检查你的车离路边有多近？如果你有足够的驾驶经验，你就会知道汽车的边缘在哪里，大致知道如何驾驶和停车，而不会撞到附近的东西

---

类似的编程性能直觉/经验对于通过尝试/错误和提问获得很重要，但你不应该花时间不断地反复检查自己。

一般来说，痴迷于性能或优化是软件开发中的一条罪恶之路。通常，只有大约5%（或更少！）的代码对整个系统的性能有任何影响。首先，作为大多数项目的软件开发人员，您的主要目标是获得正确可靠的功能，当然还有系统的可维护性。然后，一旦实施并正确工作，您将评估性能，找出瓶颈所在，并相应地优化它们以实现总体目标

对原始的系统设计和算法选择的一部分，做OO（n）类型的方法评估是合理的事情，作为一个原始系统设计和算法选择的一部分。但除此之外，大多数在实际测量瓶颈位置之前进行优化的尝试都会导致优化无关紧要的事情，通常会使事情变得不易维护、更难理解，等等。

什么时候会这样

不，说真的。有些应用程序的用户数量永远不会超过数据库中的基本索引和键关系。它们不需要调优代码的内部循环。例如，工作组大小的应用程序

随着规模的扩大，对优化路径的需求也随之增加，包括代码、数据访问和通信。如果您使用的是有限的硬件（嵌入式系统），那么您非常关心性能。但是有很多很多应用程序永远不会看到足够多的用户，以至于系统资源甚至不会注意到您的存在

---

在这种情况下，所有额外的工作都是浪费金钱和精力。在某些情况下，您的规范明确表明您需要额外的努力。在某些情况下，它清楚地表明您永远不会这样做。

您应该在构建应用程序之后，并且只有在您有证据证明瓶颈所在的情况下，才对性能进行优化。（例如，通过分析）也许你会发现没有必要进行优化，特别是因为编译器通常比你做得更好。

我有一个阶段，我对性能非常怀疑。我花了太多时间试图提高性能，以至于我的代码从来没有真正进步过。不要养成那种习惯：-）

编码，然后优化，而不是同时优化

我什么时候需要考虑性能，什么时候不需要

无论何时，只要不考虑正确性，您都可以考虑性能。：-）

---

但是，大多数时候，您的想法是“这个位的性能无关紧要：或者是因为即使使用了这个位，整个应用程序的性能仍然很好，或者是因为这个位的成本与另一个位的成本相比微不足道。”，当我处理图像处理、多个大型sql查询或循环时，我会考虑优化。否则我不会，除非我看到它工作时速度很慢。

我正在构建一个搜索引擎。优化是用户继续搜索或离开网站的区别所在。我认为这对许多应用程序来说都是正确的，不幸的是，他们中的许多人对它不够关心。有时，在这个问题上投入更多的硬件要便宜得多。不幸的是，后者更容易。总而言之，我想说，无论何时你必须处理大量数据和/或快速处理数据，你都必须进行优化。

我发现我处理一个开发单元的典型模式是：

将从头到尾贯穿主要用例的最少版本放在一起。在这一步中，我主要关注基本的简单性和应用任何模式的良好实现

第2步是重构第1步，主要着眼于简化。因为我一直在做面向对象编程，所以我似乎能够依赖的一件事是，这一步总是提供了大量明显的简化和实际的代码缩减。这也是显而易见的抽象出现的地方（这是另一种简化）。重要注意：这对解决性能问题有很大的辅助作用，特别是当您已经做了几次并且知道性能反模式在哪里时

通常情况下，当#2完成时，事情表现令人满意，但测试将证实这一点或不证实这一点；并指出需要进行优化的位置（通常很少）

---

我越来越多地看到，我在第1阶段和第2阶段花在思考高效设计上的任何时间都会弄乱简单性，这在当时是最主要的。

在让它正常工作之前，不要考虑性能。如果它工作正常，并且没有任何用户注意到的性能问题，就不要进行优化

// todo: performance could be better // try doing xyz if we need to improve it