在循环次数较少的时候一般不会发现 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。
浮点数计算的性能提升，明显大于整数，乘法的性能提升，略大于加法。
