由于嵌入式设备的盛行,而对于图像和视频处理的需求越来越高,人与机器的交互也不断的在进步,及产品中硬件成本上的考虑。所以在90年代曾消失一段时间的效率问题又重新困惑在很多研发人员身上。
什么时候才需要代码效率优化?
1. 吃饭午饭,喝杯茶,然后兴冲冲的把代码翻出来整啊整。
2. 项目进行到一半,忽然发现以前有几个地方的代码看着不顺眼,沙沙,划掉重来。
3. 程序已经在很休闲的运行着,有一天,忽然拍了怕脑袋,原来我这个代码还可以优化,然后。。。
以上都不是代码效率优化的好时机,当然,某些个人自娱自乐的代码什么时候优化是无可置非的。但是要在一个项目中忽然这么来一下,恐怕对谁来说都不是一个好事情,这样的同事谁能伤的起啊。因此在优化之前必须严格考虑,多方沟通才可以进行,并且优化之前你最好进行如下确认。
1. 这个项目至少第一轮测试已经OK,并且程序能正常运行?
(客户不停的在抱怨你们产品为什么还没有做好,你的老大不停的再你耳边不停的追问还要多久,如果你还在因为更好的性能而拼搏,那么只能以45度的角度仰望天空:“苍天啊,这个日子啥时候到头啊!”)
2. 程序在运行时效率不足,或者某些响应达不到客户的要求?
(程序已经发布,客户也确认OK了,而由于你早上走路时步子迈太大了,导致蛋蛋受伤,突然来一句,“这个地方我们可以做的更好“。然后.."滴答滴答"..再然后..”啪"..程序挂了。)
3. 除了从代码中优化之外,没有更合适的方法了,如编译器等,或者去掉一些客户不需要的功能?
(或许只需要在linux下的gcc后面加个-o3就能达到客户要求的效果了)
4. 已经找出程序中对导致性能瓶颈的代码,并且这段代码易于维护?
(通常程序中4%代码占用了50%的运行时间,而往往只需要针对这4%的代码优化就能达到要求,当你发现程序中的代码犹如天书般深奥时,那么应该尝试重构,而不仅仅是优化)
5. 你有足够的时间去优化这段代码?
(代码优化一般不是简简单单的过程,你必须有足够的耐心,它可能是这样的:完成1%--失败--失败--%5--失败...--100%)