什么时候优化才是真正值得花在上面的时间呢?

这里(至少)要提到两类“效率”:

• UI应用程序(及其依赖项),其中最重要的度量是 对用户的响应时间 .

• 批处理,主要指标是 总运行时间 .

第一种情况是 well-documented rules about response times .如果您关心产品质量,您需要保持响应时间短。当然,越短越好,但关键是:

• 100 ms的“即时”响应;动画和其他“实时”活动至少需要以这种速度发生;

• “不间断”响应1秒。除此之外,用户将感到沮丧;您还需要开始考虑显示一个超过此点的进度屏幕。

• 10秒保持用户焦点。比这更糟的是,你的用户 生气 .

如果发现多个操作耗时超过10秒,则可以使用 理智的 努力的数量(我不认为有严格的限制,但我个人肯定会说1人月以下的话,可能是3-4个月以下的话),那么你应该 一定地 努力修理它。

同样,如果你发现自己已经超过了1秒的门槛,你应该努力让它更快。至少,将改善应用程序性能所需的时间与用户可以取消的进度对话框和后台线程的每个慢屏幕重做所需的时间进行比较,因为 是 你作为设计师的责任就是在应用程序速度太慢的情况下提供这一点。

但不要仅仅基于此做出决定——用户体验也很重要。如果您需要1周时间来进行一些异步进度对话,3周时间来获得1秒以下的运行时间,那么我仍然会使用后者。在我看来,如果问题是广泛应用的话,任何低于人月的情况都是合理的;如果只是一个相对不经常运行的报告,我可能会放弃它。

如果你的应用程序是实时的——比如图形相关的——那么我会按照非实时应用程序的10秒标记对它进行分类。也就是说,你需要尽一切努力加快速度。闪烁在游戏或图像编辑器中是不可接受的。在音频处理中,口吃和故障是不可接受的。即使是像文本输入这样基本的东西,在按键和字符显示之间的500毫秒延迟是完全不可接受的,除非你通过远程桌面或其他东西连接。解决这类问题不需要付出太多的努力。

现在,对于第二个案例,我认为这基本上是不言而喻的。如果您正在进行批处理,那么通常 可扩展性 关注。只要批处理能够在分配的时间内运行,就不需要改进它。但是,如果你的数据在增长,如果一批数据应该在一夜之间运行,并且你开始看到它一直蔓延到凌晨9点15分,打断人们的工作,那么显然你需要提高性能。

事实上,你真的等不了那么久,一旦在规定的时间内不能完成,你可能已经遇到了很大的麻烦。你必须积极监控情况并保持一定的安全系数,比如说在你开始担心之前,最长的运行时间是5小时。

因此,批处理过程的答案是显而易见的。你有一个 坚硬的 要求私生子 必须 在一定时间内完成。因此,如果你接近边缘, 无论有多困难/成本多高,都必须提高性能。 问题就变成了 改进工艺最经济的方法是什么?

如果在问题上投入更多的硬件(并且你知道问题确实与硬件有关),那么不要花费任何时间优化,只需购买新的硬件。否则,找出什么样的设计优化和硬件升级的组合将使您获得最佳的投资回报率。在这一点上,这几乎完全是一个成本决定。

关于这个问题我只想说这些。对那些用“雅格尼”回应此事的人感到羞耻。你的职业责任是 知道 或者至少 找出 不管你是否“需要它”,假设在客户抱怨之前任何事情都是可以接受的,这就是放弃责任。

仅仅因为你的客户不需要它并不意味着你不需要考虑它。您的客户也不需要单元测试,甚至不需要相当好的/可维护的代码,但是您无论如何都要提供这些东西,因为它是您职业的一部分。最后,与其他以开发人员为中心的产品相比,使用平稳、快速的产品,您的客户会更高兴。

YAGNI . 除非人们抱怨,很多。

编辑 :我建立了一个比现有的备选方案稍慢的库。它仍然得到使用和分享,因为它更好地使用和更强大。我继续投资于特性和功能,推迟了性能方面的任何工作。

在某种程度上,有足够多的特性和性能冒泡到了列表的顶部,我最终花了一些时间在性能改进上,但只是在考虑了很长时间之后。

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

必要时,优化是值得的。

如果我们承诺假日包搜索的客户端响应时间不超过5秒,并且系统将在单个Oracle服务器上运行(任何规格),并且搜索在峰值负载下需要30秒,那么优化肯定是值得的,因为我们不会以其他方式获得报酬。

当您最初开发一个系统时,您(如果您是一个优秀的开发人员)正在设计一个高效的系统,而不会在过早的优化上浪费时间。如果生成的系统不够快,则需要进行优化。但你的问题似乎表明,如果你觉得值得的话,你可能会做一些手摇式的额外优化。这不是一个很好的思考方式,因为它意味着你还没有一个坚定的目标来考虑什么是可以接受的开始。在开始担心需要做什么样的优化之前,您需要与利益相关者讨论并设置某种目标。

就像大家在其他问题中所说的,答案是,当改变某件事在金钱上有意义时,它就需要改变。在大多数情况下,足够好的一天会赢。如果顾客不抱怨,那就足够好了。如果他们在抱怨,那就把它修好,这样他们就不再抱怨了。敏捷方法论将为您提供一些关于如何知道何时足够的指导。谁在乎某个东西是否比你想象的多用了40%的CPU,如果它正常工作并且客户满意,那么它就足够好了。非常简单,让它工作和维护,然后等待可能永远不会出现的投诉。

如果你担心的是一个问题,没有人会开始使用Java来构建关键任务的服务器端应用程序。或者是python或者erlang或者其他任何与C无关的东西。如果他们这样做了,在一个时间框架内什么也做不到,即使是获得第一个客户,你是如此担心失去。你会提前知道你需要在事情变成问题之前改变它。

每个人都发帖很好。

您是否看过简单选择不必要的事务用法?我被那个烫伤了几次…我还做了一些代码清理,发现有很多图被返回,可能需要10个记录……一天又一天…有时候不是你的代码本身,而是有人偷工减料……祝你好运!

如果客户机不认为需要进行性能优化,那么就没有理由这样做。

定义可度量的性能需求 SLA 当客户机(即95%的查询在2秒内完成)接近项目开始时,您可以知道您是否达到了目标,或者您是否有更多的优化工作要做。当前和预计未来负载下的性能测试为您提供了需要查看是否满足SLA的数据。

在您知道需要优化什么之前,优化很少是值得的。请始终记住,如果I/O基本上是空闲的,并且CPU很低,您就不会从计算机中得到任何东西。很明显,您不希望CPU一直处于挂接状态,也不希望I/O带宽耗尽,但要意识到在计算机执行高强度操作时,让它基本上整天处于空闲状态是不现实的。

等到你开始达到一个预先定义的阈值(80%的利用率是我通常使用的标记,其他人认为这太高/太低),然后在必要的时候进行优化。请记住,最好的解决方案可能是扩大规模或缩小规模,而不是实际优化软件。

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

也: If it ain't broke, don't fix it .

优化是值得花时间的,当你得到良好的加速,花很少的时间优化(显然)。要做到这一点,你需要引导你的工具/技术 很快 对优化效果最好的代码。

通常认为找到代码的方法是 测量函数所花费的时间 但在我看来,这只是提供线索——你还得扮演侦探。我需要什么 直奔密码 是 stackshots . Here is an example of a 40-times speedup, achieved by finding and fixing several problems. 其他人则报告了从7到60的加速因素,几乎不费吹灰之力就实现了这一目标。*

*(7X: Comment 1 . 60X: Comment 30 )