何时性能增益足以实现优化？

Question

在课本之后,每当我尝试优化代码时,我都会测量性能.然而,有时候,性能提升相当小,我无法决定性地决定是否应该实现优化.

例如,如果修复在某些条件下缩短了100ms到90ms的平均响应时间,那么我应该实现该修复吗？如果缩短200ms到190ms怎么办？在得出总体上有益的结论之前,我应该尝试多少条件？

我想这是不可能给出一个直截了当的答案,因为它取决于太多的东西,但是我应该遵循一个好的经验法则吗？有没有指南/最佳做法？

编辑:谢谢你的答案!我想这个故事的寓意是,没有简单的方法来判断你是否应该,但是有一些指导方针可以帮助这个过程.你应该考虑的事情,你不应该做的事情等等.这个特定的时间我最终实现修复,即使它在20-30行代码中生成了几行代码.因为我们的应用.在性能上非常关键,在各种现实案例中,它的增益始终为10%.

Answer 1

我认为经验法则(至少对我而言)是双重的:

1. "重要的是它是否重要" - 在商业世界中,这通常意味着如果客户关心它就很重要.也就是说,如果最终用户将"注意到"100毫秒到90毫秒之间的差异(我在这里不是很滑稽),那么这很重要.
2. 如果"这很重要",那么您将需要针对可能出现或至少可能出现的各种实际用例彻底测试您的代码.如果优化在50%的情况下加速代码,但实际上运行速度比之前的其他50%的速度慢,显然,它可能不值得实现.

关于上面的第1点:通过建议您的软件的最终用户可能"注意到"10ms的差异,我并不是说他们实际上会明显看到差异.但是,如果您的应用程序在具有数百万个连接的服务器上运行,并且每次小的速度增加都会对服务器造成很大负担,这对运行服务器的客户端来说可能很重要.或者,如果您的应用程序执行极其时间关键的工作,那么另一种情况是10ms加速的结果可能会很明显,即使加速本身不是.

Answer 2

对你的问题唯一明智的做法是"当利益足够大以保证你投资于探索,实施和测试优化的时候".

"利益足够大"是非常主观的.如果您进行此更改,您或您的雇主可以销售更多的软件单元吗？您的用户群会注意到吗？是否可以为您提供个人满足感,以获得最快的代码？哪些或类似的问题适用只有你可以知道.

总的来说,我编写的大部分软件(在20多年的职业生涯中)已经"足够快"开箱即用,而我关心优化的代码本身就是最终用户的一个明显瓶颈:查询很长一段时间,滚动太慢,那种事情.

Answer 3

唐纳德克努特在优化方面做了以下两个陈述:

"我们应该忘记小的效率,大约97%的时间说:过早的优化是所有邪恶的根源"[2]

和

"在已建立的工程学科中,容易获得的12%的改进从未被认为是微不足道的,我相信在软件工程中应该有相同的观点"[5]

src:http://en.wikipedia.org/wiki/Program_optimization