其实那个测试本身就是一个错误的测试。
为什么这样说呢？让我们来仔细分析，为求简单，只分析循环体内为空的测试。
原测试代码：
static void ForTest()
{
long length = 40000000;
Stopwatch thisStopwatch = new Stopwatch();
long[] i = new long[length];
for (long j = 0; j < length; j++)
{
i[j] = j;
}
thisStopwatch.Start();
for (long j = 0; j < i.Length; ++j)
{
}
thisStopwatch.Stop();
Console.WriteLine(thisStopwatch.Elapsed.Milliseconds);
}
static void ForeachTest()
{
long length = 40000000;
Stopwatch thisStopwatch1 = new Stopwatch();
long[] i = new long[length];
for (long j = 0; j < length; j++)
{
i[j] = j;
}
thisStopwatch1.Start();
foreach (long j in i)
{
}
thisStopwatch1.Stop();
Console.WriteLine(thisStopwatch1.Elapsed.Milliseconds);
}
这个测试代码和飞林沙的原文比，略有变动。主要是去掉了length的const。
我的测试结果：for -- 147 foreach -- 82
直接将i.Length替换成length，测试结果：for -- 88 foreach -- 82
就这两个测试而言，貌似可以得出这样一个结论：
（1）只读式集合foreach比for快
（2）在循环体中使用i.Length比使用length要慢很多
实际上这两个结论都是错误的。错误的原因，在于这个测试本身就是一个不公平的测试。对for很不公平。
用reflector反编译。
（a）
for (long j = 0; j < i.Length; ++j)
{
}
=>
for (long j = 0L; j < numArray2.Length; j += 1L)
{
}
（b）
for (long j = 0; j < length; ++j)
{
}
=>
for (long j = 0L; j < 0x2625a00L; j += 1L)
{
}
（c）
foreach (long j in i)
{
}
=>
for (int j = 0; j < numArray2.Length; j++)
{
long num1 = numArray2[j];
}
可以看出，这里影响性能的关键是 Int32和Int64 的差别。for (long j = 0; j < i.Length; ++j)
{
}
=>
for (long j = 0L; j < numArray2.Length; j += 1L)
{
}
（b）
for (long j = 0; j < length; ++j)
{
}
=>
for (long j = 0L; j < 0x2625a00L; j += 1L)
{
}
（c）
foreach (long j in i)
{
}
=>
for (int j = 0; j < numArray2.Length; j++)
{
long num1 = numArray2[j];
}
（a）中主要是Int64的计算，还涉及到一个Int32 (numArray2.Length)到Int64的转变。
（b）中主要是Int64的计算，不过不涉及到Int32到Int64的转变，因此比（a）快得多。
（c）中主要是Int32的计算，其中也涉及到一个Int32到Int64的转变。至于（c）比（b）略快，这里可以看出，对于这个例子而言，编译器将foreach转变成了for循环。（c）和（b）的性能差别，其实是Int32计算+Int32->Int64计算和纯Int64计算的差别。
从（c）中也可以看见编译器傻X的一面。明明j没被调用，它还要偏偏的将它转化出来。
所以说，飞林沙的测试是个错误的测试。为使公平起见，需要将测试代码中的long全部改成Int32。
测试结果：
for中使用i.Length： for -- 22, foreach -- 52
for中不使用i.Length: for -- 21, foreach -- 52
为什么 foreach 比 for 慢这么多呢？原因上面说过，编译器太傻X了，在循环体中加了条语句：int num1 = numArray2[j];
下面谈一谈编译器的优化问题。
我们和编译器相比，各自优势是什么？
我们比编译器更清楚我们的代码是干什么用的，但在代码的执行原理上比不上编译器（其实是比不上写编译器的那些人），比如，《for和foreach，N个人N种结论的选择》原文作者就没考虑到Int32和Int64的问题。当然，牛人牛到一定程度，比写编译器的人还牛，也是很有可能的。
编译器比我们更清楚代码的执行原理，但是它不知道我们这行代码是干什么用的。它的优化是有前提的，第一点是不能出错误，第二点是优化的通用性。另外一点，编译器的聪明也是有限的。这几点导致编译器的优化绝大部分情况下不是最佳的优化。
有很多优化策略确实可以将程序性能提高很多，但是如果不能保证程序的正确性，编译器倾向于不做这样的优化。而人工写代码，可以在代码中或者在应用中确保这种程序错误不会出现，就可以手动的选择这种优化策略。关于编译器优化，《深入理解计算机系统》一书 第5章 优化程序性能 讲的很精彩。
所以我认为，一般情况下foreach是比for效率低一点的，只要for循环写的不是太差。
针对 《for和foreach，N个人N种结论的选择》 文后的回复，我觉得有几个错误的看法需要指出。
（1）所谓 for 有条件检查，foreach不要条件检查
诚然，for每一促循环都要判断循环条件是否成立，难道foreach中每一次迭代都不需要判断当前迭代器的位置是否到头？
（2）判断越界问题
判断索引的越界，在越界时抛出异常，是容器的职责，而不是调用它的代码的职责。这一问题和for和foreach都无关系。在语义上，for与foreach并不保证不越界。这是最基本的职责分离原则，微软如果把for, foreach和越界混在一起，将是软件界的一大笑话。
很简单的一个例子：
for(int i = 1000; i<(myarray.Length)*2;i=i+2)
{
}
编译器你去判断去吧。
勿在浮沙筑高塔。