本文并非讨论类似哪个语言效率最高等无聊的编程语言之争,也不像《effective c》等讲述某个语言的优化问题,本文只是讨论编程习惯对程序性能的影响。
如果你是一个农夫,那么给你倚天剑你也只会用来锄地,而且会抱怨效果还没锄头好,如果你是一个高手,即使是摘叶飞花,也可伤敌。所以说什么语言不重要,关键还是看人。
这里先介绍一个心得,叫做低代价优先返回原则。
低代价优先返回原则
对于一段代码,应该优先处理低代价的逻辑,低代价的逻辑包括:
1.纯CPU计算,不需要访问网络、io、数据库的逻辑。
纯CPU计算部分是最快的,应该最优先判断,不通过就直接返回,不再计算后面的网络、io、数据库逻辑。如果纯CPU计算部分的判断不通过,则后续需要用到网络、io、数据库的逻辑部分就可以免除了,这样可以大大减少各种io等待。
2.失败几率最高的逻辑。
假如一段代码中,有A->B->C->D->OK, 四个判断阶段,其中D阶段的淘汰率最高,C次之,A、B再次之,那么处理顺序应该改为D->C->A->B->OK,这样在第一个判断阶段就过滤了大量的数据流入第二阶段,减少了非常多无谓的A、B阶段的处理。
这里举一个例子:
曾经看到一份代码,先将所有需要计算的数据都统一计算好,然后再进行数据的条件判断,不符合条件则返回,伪代码如下:
void select(p) { a = calA(p); b = calB(p); c = calC(p); d = calD(p); if (a>0 && b < 0 && c < 100 && d > 5) { OK } else { FAIL } }
估计很多人都很乐意写这样的代码,感觉上就是逻辑清晰,计算数据,筛选数据,两个步骤很明晰。特别是在某些框架中,提供的接口还强制约束着必须这样按部就班地实现。
这个程序在执行某一个大数据量的数据逻辑处理,需要花费3天时间
将代码改为:
void select(P) { d = calD(p); //d的淘汰率最高 if (d <= 5) { return; } c = calC(p); /// 淘汰率次之 if (c >= 100) { return; } a = calA(p) ; if (a <= 0) { return; } b = calB(p); if (b >=0 ) { return; } OK }
改代码后,同样的数据处理,只需要十几分钟就完成了。
我相信,在你们的项目中,找一找上面那种低效率的代码,肯定不少!