什么时候优化真的值得花费在它上面的时间？

Question

在我的last question之后，我想了解何时优化真的值得开发人员花费时间。

是否值得花4个小时才能获得快20％的查询？是的，不，也许，是的，如果......？

“浪费”7个小时将任务切换到另一种语言以节省大约40％的CPU使用量“值得”吗？

我对新项目的正常迭代是：

1. 了解客户想要什么，以及他需要什么;
2. 规划项目：什么语言和地点，数据库设计;
3. 开发项目;
4. 测试和错误修复;
5. 正在运行的项目和最终优化的最终分析;
6. 如果项目需要，进一步分析资源的实际使用情况，然后进一步优化;

隐含“写好，可维护的代码”。

显然，大的'优化'部分发生在第2点，但通常在项目结束后审查代码时，我发现有些部分，即使他们做得好，也可以改进。这是第5点的基本原理。

为了给出最后一点的具体示例，一个简单的例子是当我希望90％的查询为SELECT而10％为INSERT/UPDATE时，所以我向数据库表收取索引。但是在6个月之后，我发现在现实生活中有10％SELECT个查询和90％INSERT/UPDATE个查询，因此查询速度没有得到优化。这是第一个出现在我脑海中的例子（显然，对于最初的错误设计而言，这更像是一个'补丁'而不是优化;）。

请注意我是开发人员，而不是商人 - 但我希望在可能的情况下尽最大努力为客户提供良好的良心。

我的意思是，我知道如果我失去了50个小时来获得应用程序总速度的5％，并且应用程序被10个用户使用，那么它可能不值得花时间......但是什么时候？

您认为优化何时至关重要？

您通常使用什么公式，意识到优化时间（以及最终收益）并不总是可以在纸上量化？

编辑：对不起，但是我不能接受像“直到人们不抱怨id，不需要优化”这样的答案;它可以是一个商业视图（可疑，imho），但不是开发人员或（imho）一个良好的答案。我知道，这个问题确实很主观。

我同意Cheeso，在对项目的实际使用情况和负载进行一些分析之后，应该推迟性能优化，但是在项目结束后可以立即进行小的优化。

感谢所有人;）

Answer 1

YAGNI。除非人们抱怨，否则很多。

---

编辑：我构建了一个比其他选项稍慢的库。它仍然获得了使用和分享，因为它使用起来更好，功能更强大。我继续投入功能和能力，推迟任何性能方面的工作。

在某些时候，有足够的功能和性能冒泡到列表的顶部我最终花了一些时间来进行性能提升，但只是在考虑了很长时间的努力之后。

我认为这是接近它的正确方法。

Answer 2

Answer 3

在必要时，优化是值得的。

如果我们承诺客户响应时间为5秒或更短的假期包搜索，并且系统将在单个Oracle服务器上运行（无论什么规格）并且搜索在峰值负载下花费30秒，那么优化绝对是值得的，因为否则我们不会得到报酬。

当您最初开发系统时，您（如果您是一名优秀的开发人员）正在设计高效的东西，而不会浪费时间进行过早优化。如果生成的系统不够快，则进行优化。但是你的问题似乎表明，如果你觉得它值得，你可能会做一些手动的额外优化。这不是一个考虑它的好方法，因为它意味着你没有牢牢考虑到可以接受的东西。在开始担心需要进行哪种优化之前，您需要与利益相关者讨论并设置某种目标。

Answer 4

就像所有人在其他问题中所说的那样，答案是，当它改变某些东西时具有金钱意义，那么它需要改变。在大多数情况下，足够好赢得一天。如果客户没有抱怨，那就足够了。如果他们抱怨，那就解决它，以免他们停止抱怨。敏捷方法将为您提供有关如何知道何时足够的指导。谁在乎使用40％CPU的CPU比你想象的要多得多，如果它工作正常并且客户满意则那就足够了。非常简单，让它工作和维护，然后等待可能永远不会到来的投诉。

如果您担心的确是一个问题，那么NO ONE就不会开始使用Java来构建关键任务服务器端应用程序。或Python或Erlang或其他任何不是C的东西。如果他们这样做了，那么在一个时间框架内什么都不会做，甚至无法获得你担心失去的第一个客户。你会事先知道在成为问题之前需要改变一些东西。

Answer 5

很好地张贴每个人。

您是否查看了简单SELECT（s）的不必要的事务用法？我被烧了几次......我也做了一些代码清理工作，发现很多图表都需要返回，可能需要10条记录....等等......有时它不是你的代码本身，而是有人切割角落......祝你好运！

Answer 6

如果客户端没有看到需要进行性能优化，那么没有理由这样做。

在项目开始附近与客户定义可衡量的性能要求SLA（即95％的查询在2秒内完成）可让您知道您是否达到了目标，或者您是否已达到目标做更多优化。在当前和估计的未来负载下进行性能测试可以为您提供在满足SLA时所需的数据。

Answer 7

在您了解需要优化的内容之前，优化很少值得。永远记住，如果I / O基本上处于空闲状态并且CPU很低，那么你就不会从计算机中获取任何东西。显然你不希望CPU一直挂着你并且你不想耗尽I / O带宽，但是意识到在执行紧张操作的同时让计算机基本上闲置一整天是不现实的。

等到你开始达到预定义的阈值（80％利用率是我经常使用的标记，其他人认为太高/低）然后在必要时进行优化。请记住，最佳解决方案可能是扩展或扩展，而不是实际优化软件。

Answer 8

优化是值得花费的时间，当你获得良好的加速，花费很少的时间进行优化（显然）。要实现这一点，您需要能够非常快地使用优化产生最大效益的代码的工具/技术。

通常认为找到代码的方法是通过测量函数花费的时间，但在我看来，这只提供线索 - 你仍然需要扮演侦探。我直接访问代码的原因是stackshots。 Here is an example of a 40-times speedup, achieved by finding and fixing several problems. SO上的其他人报告说加速因子从7到60，只需很少的努力就可以实现。*

*（7x：Comment 1。60x：Comment 30。）

Answer 9

使用Amdal's law。它向您展示了优化系统某个部分时的整体改进。

另外：If it ain't broke, don't fix it。