关于一些代码效率优化的方法(上)

 

      由于嵌入式设备的盛行,而对于图像和视频处理的需求越来越高,人与机器的交互也不断的在进步,及产品中硬件成本上的考虑。所以在90年代曾消失一段时间的效率问题又重新困惑在很多研发人员身上。

 

      什么时候才需要代码效率优化?

 

      1. 吃饭午饭,喝杯茶,然后兴冲冲的把代码翻出来整啊整。

      2. 项目进行到一半,忽然发现以前有几个地方的代码看着不顺眼,沙沙,划掉重来。

      3. 程序已经在很休闲的运行着,有一天,忽然拍了怕脑袋,原来我这个代码还可以优化,然后。。。

 

      以上都不是代码效率优化的好时机,当然,某些个人自娱自乐的代码什么时候优化是无可置非的。但是要在一个项目中忽然这么来一下,恐怕对谁来说都不是一个好事情,这样的同事谁能伤的起啊。因此在优化之前必须严格考虑,多方沟通才可以进行,并且优化之前你最好进行如下确认。 

     1. 这个项目至少第一轮测试已经OK,并且程序能正常运行?      

      (客户不停的在抱怨你们产品为什么还没有做好,你的老大不停的再你耳边不停的追问还要多久,如果你还在因为更好的性能而拼搏,那么只能以45度的角度仰望天空:苍天啊,这个日子啥时候到头啊!) 

     2. 程序在运行时效率不足,或者某些响应达不到客户的要求?

     (程序已经发布,客户也确认OK了,而由于你早上走路时步子迈太大了,导致蛋蛋受伤,突然来一句,这个地方我们可以做的更好。然后.."滴答滴答"..再然后..”"..程序挂了。) 

     3. 除了从代码中优化之外,没有更合适的方法了,如编译器等,或者去掉一些客户不需要的功能?

      (或许只需要在linux下的gcc后面加个-o3就能达到客户要求的效果了)

     4. 已经找出程序中对导致性能瓶颈的代码,并且这段代码易于维护?

      (通常程序中4%代码占用了50%的运行时间,而往往只需要针对这4%的代码优化就能达到要求,当你发现程序中的代码犹如天书般深奥时,那么应该尝试重构,而不仅仅是优化)

     5. 你有足够的时间去优化这段代码?

      (代码优化一般不是简简单单的过程,你必须有足够的耐心,它可能是这样的:完成1%--失败--失败--%5--失败...--100%

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值