在循环次数较少的时候一般不会发现 for 循环的写法会对效率产生多大问题,但一旦循环次数较多,比如说上万,循环层数较多,效率问题就非常明显了,我是在做一个数据量非常大有三层 for 循环的项目的时候,为显示曲线出来太花费时间,客户体验会非常不好,才研究这个情况的,事实证明,优化后的多重 for 循环提升了一大半的效率,是不是很神奇。
当然,本文也有借鉴其他同胞的方法。

实例化变量放在 for 循环外,减少实例化次数,尽量只实例化一次;

普通变量 改为 寄存器变量
i++ 改为 ++i

int i=0, j;
j=++i; // 前置版本,运算对象先自增 1,然后将改变后的对象作为求值结果,再赋值给 j;
j=i++; // 后置版本,先赋值给 j;再运算对象自增 1,但求值结果是运算对象改变之前那个值的副本.

C++Primer 中解释:前置版本的递增运算符避免了不必要的工作,它把值加 1 后直接返回改变了的运算对象。与之相比,后置版本需要将原始值存储下来以便于返回这个未修改的内容,如果我们不需要修改前的值,那么后置版本的操作就是一种浪费。

for(int i = 0; i<50; i++)
循环条件使用 <要快于 <=,> 和 >= 同理;

把外层可以计算的尽可能放到外层,减少在内层的运算,有判断条件的语句和与循环不相关的操作语句尽量放在 for 外面;

应当将最长的循环放在最内层,最短的循环放在最外层,以减少 CPU 跨切循环层的次数;
采用的是行优先访问原则,与元素存储顺序一致。

对于一个可结合和可交换的合并操作来说,比如整数的加法或乘法,
我们可以通过将一组合并操作分割成 2 个或更多的部分,并在最后合并结果来提高性能。

原理:
普通代码只能利用 CPU 的一个寄存器,分割后可以利用多个寄存器。
当分割达到一个数量时,寄存器用完,性能不再提升,甚至会开始下降。
用代码来描述,如下:

// 一般情况下的代码 for (i = 1; i < n+1; i++)
 {
     res = res OPER i;
 }// 循环分割后代码 for (i = 1; i < n; i+=2)
 {
     res1 = res1 OPER i;
     res2 = res2 OPER (i+1);
 }

int 整数加法,性能测试结果对比如下:
整数的加法,普通代码运行 26s,循环分割后,18s。
浮点数计算的性能提升,明显大于整数,乘法的性能提升,略大于加法。