C#中for和foreach循环的性能

大家先来看看如下三个循环：

int[] foo = new int[100];

1，

1. foreach (int i in foo)
   
2. Console.WriteLine(i.ToString());
   

复制代码

2，

1. for(int index=0;index<foo.Length;index++)
   
2. Console.WriteLine(foo[index].ToString());
   

复制代码

3，

1. int len=foo.Length;
   
2. for(int index=0;index<len;index++)
   
3. Console.WriteLine(foo[index].ToString());
   

复制代码

这三个循环是我在看《 Effective C# 中文版（改善程序的50种方法）PDF下载》中看到的，发现书中说第三个循环和如下代码等效，经过使用ILDasm.exe 工具查看IL代码发现这个说法并不正确：

1. int len=foo.Length;
   
2. 
   
3. 
   
4. for(int index=0;index<len;index++)
   
5. 
   
6. {
   
7. 
   
8.       if(index<foo.Length)
   
9. 
   
10.           Console.WriteLine(foo[index].ToString());
    
11. 
    
12.       else
    
13. 
    
14.             throw new IndexOutOfRangeException();
    
15. 
    
16. }
    

复制代码

书中的看法是数组的边界 测试会被执行两次（编译器生成的代码一次，JIT编译阶段还要执行一次检查），但是的确没有在IL代码中发现C#的编译器生成类似的逻辑，所以这个说法有问题！

一般C++转过来的程序员都很喜欢这样写循环，认为这样就不会每一次循环都计算一次Length属性的值了，可以带来 性能上的提升！经查看IL代码，实际情况也就是如此！


但是，这样写会带来另外的问题，那就是破坏了JIT对代码的进行的 优化，这样的写法在每一次循环中都要做数组的边界检查，这样也带来了性能上的损失，而且这个损失要比每次计算Length要大，如果我们按第二种写法，JIT只在第一次循环之前检查一次数组界限（JIT这种优化只针对f循环中访问一维0基数组，并且索引是0和Length之间的元素）

看来JIT不喜欢我们这样帮助他优化代码，这样反而破坏了JIT本身的优化！


我们再来看看第一种写法和第二种写法，通过查看IL代码，他们生成的代码比较类似，差别是使用foreach循环是把数组元素放到i变量里！


C#编译器对第一种写法（使用foreach循环）针对数组做了特殊的处理，并没有像其他集合那样在内部使用迭代器，这里如果使用迭代器的话会导致装箱和拆箱操作，这样会带来性能上的损失！看来C#编译器总是可以为foreach生成很高效率的代码，而且可以带来很多其他的好处，例如简化代码的编写，或是将来把foo变成其他集合 而foreach循环不必修改（使用for循环必须修改代码），操作数强制类型转换等。