When is the optimization really worth the time spent on it?
在我最后一个问题之后，我想了解什么时候优化才是真正值得开发人员花在优化上的时间。
花4个小时快速处理20%的查询是否值得？是的，不，也许，是的，如果…？
为了节省大约40%的CPU使用量，将一个任务切换到另一种语言是否浪费了7个小时？
我对新项目的正常迭代是：
暗含"编写良好、可维护的代码"。
显然，大的"优化"部分发生在第2点，但通常在项目结束后检查代码时，我会发现一些部分，即使它们做得很好，也可以改进。这就是第5点的基本原理。
为了给出最后一点的具体示例，一个简单的示例是，当我期望90%的查询是
请注意，我是一个开发人员，而不是一个商人-但我喜欢有一个明确的良心，给我的客户最好的，如果可能的话。
我的意思是，我知道如果我浪费50个小时来获得应用程序总速度的5%，而应用程序被10个用户使用，那么它可能不值得花时间……但什么时候呢？
你认为什么时候优化是至关重要的？
你通常采用什么公式，知道花在优化(和最终收益)上的时间并不总是可以在纸上量化的？
编辑：对不起，我不能接受这样的回答："除非所有人都不抱怨ID，不需要优化"；它可以是一个业务视图(有问题，imho)，但不是一个开发人员或(imho也是)一个很有意义的答案。我知道，这个问题很主观。
我同意Cheeso的观点，在对项目的实际使用和负载进行分析之后，性能优化应该推迟，但是在项目结束后，可以立即进行一个小的、不快速的优化。
感谢所有人；)
亚尼除非人们抱怨，很多。
编辑：我建了一个图书馆，比外面的其他图书馆稍微慢一点。它仍然得到使用和分享，因为它更好地使用和更强大。我继续投资于特性和功能，推迟了性能方面的任何工作。
在某种程度上，有足够的特性和性能冒泡到了列表的顶部，我最终花了一些时间在性能改进上，但只是在考虑了很长时间之后。
我认为这是接近它的正确方法。
这里(至少)提到两类"效率"：好的。
UI应用程序(及其依赖项)，其中最重要的度量是对用户的响应时间。好的。
批处理，主要指标是总运行时间。好的。
在第一种情况下，关于响应时间有很好的记录规则。如果您关心产品质量，您需要保持响应时间短。当然，越短越好，但关键是：好的。
100 ms的"即时"响应；动画和其他"实时"活动至少需要以这种速度发生；好的。
"不间断"响应1秒。除此之外，用户将感到沮丧；您还需要开始考虑显示一个超过此点的进度屏幕。好的。
10秒保持用户焦点。更糟的是，你的用户会很生气。好的。
如果你发现几个操作需要超过10秒，你可以用理智的努力来解决性能问题(我不认为有严格的限制，但我个人认为在1人月以下肯定会说任何事情，可能在3-4个月以下)，那么你一定要把精力放在解决问题上。好的。
同样，如果你发现自己已经超过了1秒的门槛，你应该努力让它更快。至少，将改善应用程序性能所需的时间与用户可以取消的进度对话框和后台线程的每一个慢屏幕重做所需的时间进行比较，因为如果应用程序太慢，作为设计师，您有责任提供这一点。好的。
但不要仅仅以此为基础做出决定——用户体验也很重要。如果您需要1周时间来进行一些异步进度对话，3周时间来获得1秒以下的运行时间，那么我仍然会使用后者。在我看来，如果问题是广泛应用的话，任何低于人月的情况都是合理的；如果只是一个相对不经常运行的报告，我可能会放弃它。好的。
如果你的应用程序是实时的——比如图形相关的——那么我会按照非实时应用程序的10秒标记对它进行分类。也就是说，你需要尽一切努力加快速度。闪烁在游戏或图像编辑器中是不可接受的。在音频处理中，口吃和故障是不可接受的。即使是像文本输入这样基本的东西，在按键和字符显示之间的500毫秒延迟是完全不可接受的，除非你通过远程桌面或其他东西连接。对于解决这类问题，任何努力都不过分。好的。
现在，对于第二个案例，我认为这主要是不言而喻的。如果您正在进行批处理，那么通常会有一个可伸缩性问题。只要批处理能够在分配的时间内运行，就不需要改进它。但是，如果你的数据在增长，如果一批数据要在一夜之间运行，你会发现它一直蔓延到凌晨的凌晨，在上午9:15中断人们的工作，那么显然你需要提高性能。好的。
事实上，你真的等不了那么久，一旦在规定的时间内完成不了，你可能已经遇到了很大的麻烦。你必须积极监控情况并保持一定的安全系数，比如说在你开始担心之前，最长的运行时间是5小时。好的。
因此，批处理过程的答案是显而易见的。你有一个很难的要求，那就是混蛋必须在一定时间内完成。因此，如果您接近边缘，无论它有多困难/成本多高，都必须提高性能。然后，问题就变成了改进工艺的最经济的方法是什么？好的。
如果在问题上投入更多的硬件(并且你知道问题确实与硬件有关)，那么不要花费任何时间优化，只需购买新的硬件。否则，找出什么样的设计优化和硬件升级的组合将使您获得最佳的投资回报率。在这一点上，这几乎完全是一个成本决定。好的。
关于这个问题我只想说这些。对那些用"雅格尼"回应此事的人感到羞耻。你的职业责任是知道或者至少知道你是否"需要它"，假设在客户抱怨之前任何事情都是可以接受的，这是你放弃这个责任的原因。好的。
仅仅因为你的客户不需要它并不意味着你不需要考虑它。您的客户也不需要单元测试，甚至不需要相当好的/可维护的代码，但是您无论如何都要提供这些东西，因为它是您职业的一部分。最后，与其他以开发人员为中心的产品相比，使用平稳、快速的产品，您的客户会更高兴。好的。好啊。
必要时，优化是值得的。
如果我们承诺假日包搜索的客户端响应时间不超过5秒，并且系统将在单个Oracle服务器上运行(无论是什么规格)，并且搜索在峰值负载下需要30秒，那么优化肯定是值得的，因为我们不会以其他方式获得报酬。
当您最初开发一个系统时，您(如果您是一个优秀的开发人员)正在设计一个高效的系统，而不会在过早的优化上浪费时间。如果生成的系统不够快，则需要进行优化。但你的问题似乎表明，如果你觉得值得的话，你可能会做一些手摇式的额外优化。这不是一个很好的思考方式，因为它意味着你还没有一个坚定的目标，什么是可以接受的开始。在开始担心需要做什么样的优化之前，您需要与利益相关者讨论并设定某种目标。
每个人都发帖很好。
您是否看过简单选择不必要的事务用法？我被那个烫伤了几次…我还做了一些代码清理，发现有很多图被返回，可能需要10个记录…继续…有时候这不是你的代码本身，而是有人偷工减料……祝你好运！
就像大家在其他问题中所说的，答案是，当改变某件事在金钱上有意义时，它就需要改变。在大多数情况下，足够好的一天会赢。如果顾客不抱怨，那就足够好了。如果他们在抱怨，那就把它修好，这样他们就不再抱怨了。敏捷方法论将为您提供一些关于如何知道何时足够的指导。谁在乎某个东西是否比你想象的多用了40%的CPU，如果它正常工作并且客户满意，那么它就足够好了。非常简单，让它工作和维护，然后等待可能永远不会出现的投诉。
如果你担心的是一个问题，没有人会开始使用Java来构建关键任务的服务器端应用程序。或者是python或者erlang或者其他任何与C无关的东西。如果他们这样做了，在一个时间框架内什么也做不到，即使是获得第一个客户，你是如此担心失去。你会提前知道你需要在事情变成问题之前改变它。
使用阿姆达尔定律。它向您展示了优化系统某个部分时的整体改进。
还有：如果没有坏，就不要修。
优化是值得花时间的，当你得到良好的加速，花很少的时间优化(显然)。要做到这一点，您需要工具/技术，这些工具/技术可以很快地引导您找到优化带来最大好处的代码。
人们通常认为，找到代码的方法是通过测量函数所花费的时间，但在我看来，这只提供了线索——你仍然必须扮演侦探角色。让我直接了解代码的是stackshots。这里有一个例子，通过发现和解决几个问题，加速了40倍。其他人则报告了从7到60的加速因素，几乎不费吹灰之力就实现了这一目标。*
*(7X：评论1。60倍：评论30。)
在您知道需要优化什么之前，优化很少是值得的。请始终记住，如果I/O基本上是空闲的，并且CPU很低，您就不会从计算机中得到任何东西。很明显，您不希望CPU一直处于挂接状态，也不希望I/O带宽耗尽，但要意识到在计算机执行高强度操作时，让它基本上整天处于空闲状态是不现实的。
等到你开始达到一个预定义的阈值(80%的利用率是我通常使用的标记，其他人认为这太高/太低)，然后在必要的时候进行优化。请记住，最好的解决方案可能是扩大规模或缩小规模，而不是实际优化软件。
如果客户机不认为需要进行性能优化，那么就没有理由这样做。
在项目的开始附近定义一个可度量的性能需求SLA(即95%的查询在2秒内完成)，可以让您知道您是否达到了这个目标，或者您是否有更多的优化工作要做。当前和预计未来负载下的性能测试为您提供了需要查看是否满足SLA的数据。