优化代码

您将获得一堆用您喜欢的语言编写的代码,这些代码组合起来形成一个相当复杂的应用程序 它运行得相当慢,你的老板要求你优化它.您最有效地优化代码的步骤是什么？

在优化代码时,您发现哪些策略不成功？

重写:在什么时候你决定停止优化并说"这是没有完全重写的速度." 在什么情况下你会提倡简单的完全重写？你会如何设计呢？

1> Mitch Wheat..：

---

在尝试任何优化之前的配置

10次​​中有9次,时间不会消耗在您可能猜到的地方.

通常不成功的策略是微优化,当实际需要的是适当的算法时.

必要的唐纳德克努特引述:

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

---

同意,如果没有基线,优化就无济于事.如果你无法衡量它,你就无法改进它.

2> angry person..：

---

脚步:

测量

分析

决定

实行

重复

首先得到一个分析器来测量代码.不要陷入假设你知道瓶颈在哪里的陷阱.即使之后,如果您的假设被证明是正确的,也不要认为您可以在下次执行类似任务时跳过测量步骤.

然后分析你的发现.查看代码,找出可以做些什么的瓶颈会产生影响.试着估计这将有多大改进.

根据您的分析,决定是否要沿着这条路走下去.收益是否值得？是否需要重写？也许你会发现虽然它运行缓慢,但是它会达到或者你接近性能曲线的顶部,在那里需要努力寻求微小的改进是不合理的.

实现您的更改,必要时进行重写,或者重构代码(如果这是您已经失败的路径).以小步骤进行操作,以便在您的更改给出您想要的内容或者您需要回溯步骤并尝试不同路线时更容易测量.

然后回到开始并测量,分析,决定,实施等.

另外,关于重构代码的说明.您应该改变的第一件事是大算法级别的方法.比如将排序算法替换为性能更好的排序算法等等.不要从行级优化开始,比如如何获得一个增加值的行稍快一点.这些是最后一级优化,通常不值得,除非您在极端性能条件下运行.

---

你忘了0:定义如果没有"慢","快","足够快","性能","速度"等等的精确定义,你永远不会知道什么时候完成.事实上,你甚至都不知道自己是否取得了进步.此外,您将无法执行#1,因为您不知道要测量什么.

3> Simon Buchan..：

---

甚至不费心去尝试任何事情 没有一些类型的分析中,我不能强调这就够了!不幸的是,我所知道的所有剖析器都很糟糕或者很昂贵(不管是商业成本!)所以我会让其他人在那里提出建议:).

当你的数据告诉你需要重写时,你知道你需要重写,这听起来是递归的,但实际上只是意味着当前架构或软件堆栈的成本本身足以让你超越性能悬崖,所以你在本地更改中所做的任何事情都无法解决整体问题.但是,在你拿出File-> New ...命令之前,制定一个计划,构建一个原型并测试原型比同一任务的当前系统做得更好:令人惊讶的是,经常没有明显的区别!