起因
昨天看到了一篇文章，说到并行库的效率问题，在最后lz也发现是因为CPU的超线程技术，导致实际效率不能接近算上开启超线程的核心数量，而在接近关闭超线程的核心数量。不过文中提到了一点：“不过另一个问题有也出来了，为什么我那简单的改进算法相对效率那么高。”
分析
原作者在今天又发文章说是循环方式的不同导致差异，虽然没有点击中要害，不过也算是给出了个范围。
首先准备一个测试工程：
class Program
{
private long[] data;
static void Main(string[] args)
{
Program p = new Program();
p.Test();
}
public Program()
{
var random = new Random();
data = Enumerable.Range(1, 67108864)
.Select(i => (long)random.Next(int.MaxValue))
.ToArray();
}
private void Test()
{
// todo : add test.
}
}
直接使用原文中的long[]做为测试依据，这里先定义4个测试项目：
private void TestPLinqSum()
{
// warm up.
(new long[10]).AsParallel().Sum();
Stopwatch w = new Stopwatch();
w.Start();
var sum = data.AsParallel().Sum();
w.Stop();
Console.WriteLine("PLinq Sum:{0}", w.ElapsedMilliseconds);
}
private void TestLinqSum()
{
Stopwatch w = new Stopwatch();
w.Start();
var sum = data.Sum();
w.Stop();
Console.WriteLine("Linq Sum:{0}", w.ElapsedMilliseconds);
}
private void TestForSum()
{
Stopwatch w = new Stopwatch();
w.Start();
var sum = 0L;
for (int i = 0; i < data.Length; i++)
sum += data[i];
w.Stop();
Console.WriteLine("For Sum:{0}", w.ElapsedMilliseconds);
}
private void TestForeachSum()
{
Stopwatch w = new Stopwatch();
w.Start();
var sum = 0L;
foreach (var item in data)
sum += item;
w.Stop();
Console.WriteLine("Foreach Sum:{0}", w.ElapsedMilliseconds);
}
分别测试PLinq，Linq，For和Foreach的消耗时间，在双核+Release方式（要是用Debug跑出来的，一定不是这个结果。。。）执行，测试结果如下：
PLinq Sum:313
Linq Sum:595
For Sum:195
Foreach Sum:89
可以发现Foreach的效率最高（无比强大的编译器优化。。。），For次之，PLinq的数据可能会不太稳定，不过通常比Linq的快一些，Linq的Sum垫底。
乍看下来，似乎结论就是Linq是垃圾，纯粹在浪费性能，PLinq是在Linq浪费性能的基础上，再用上多核，所以还是垃圾。
不过等等，是不是少了什么？
这个测试存在一些不公平的因素，导致Linq的性能看其来如此之差。
原因在于数据源：数组
看文章
为什么说数组是导致这个结论的元凶哪？先来看msdn上关于性能的一片文章。
文章中虽然没写从数组中取一个元素的效率是多少，不过写了写入一个数组元素的效率，两者应该相差不会太大，来看看对比吧：
| Operation Measured | Median | Mean | StdDev | Min | Max | Samples |
| MethodCalls: EmptyStaticFunction() [count=1000 scale=10.0] | 1.000 | 1.005 | 0.084 | 0.922 | 1.136 |
10 |
| MethodCalls: aClass.Interface() [count=1000 scale=10.0] | 1.699 | 1.769 | 0.090 | 1.696 | 1.943 |
10 |
| ObjectOps: new Class() [count=1000 scale=10.0] | 6.248 | 8.040 | 3.556 | 5.087 | 16.296 |
10 |
| Arrays: aIntArray[i] = 1 [count=1000 scale=10.0] | 0.616 | 0.638 | 0.071 | 0.612 | 0.850 |
10 |
| Delegates: aInstanceDelegate() [count=1000 scale=10.0] | 1.233 | 1.244 | 0.088 | 1.160 | 1.398 |
10 |
| PInvoke: FullTrustCall() [count=1000] | 7.452 | 6.946 | 0.804 | 5.878 | 7.913 |
10 |
| Locks: Monitor lock [count=1000] | 11.487 | 12.129 | 0.901 | 11.322 | 13.843 |
10 |
从列表中不难发现写入一个int[]元素的代价远小于调用一个接口方法的代价（接口方法的实现是什么也不做）。
回头看看之前的对比，一个是Linq的Sum方法，方法签名是：long Sum(IEnumerable<long>)，里面的实现，大家猜也猜得到，无非就是：
private static long MySum(IEnumerable<long> source)
{
long result = 0L;
foreach (var item in source)
{
result += item;
}
return result;
}
如果还记得前面的测试结果，一定会说，ForEach的性能很好的，排第一，不过等等，前面也说了，这是因为有无比强大的编译器优化导致的，那么，再加一个测试：
private void TestForeachSumByInterface()
{
Stopwatch w = new Stopwatch();
w.Start();
var sum = 0L;
foreach (var item in (IEnumerable<long>)data)
sum += item;
w.Stop();
Console.WriteLine("Foreach Sum (by interface):{0}", w.ElapsedMilliseconds);
}
与前面的ForEach的区别仅仅是显式的指明data的类型是IEnumerable<long>，再来看看执行结果吧：
PLinq Sum:322
Linq Sum:597
For Sum:204
Foreach Sum:89
Foreach Sum (by interface):546
ForEach的成绩依然遥遥领先，但是ForEach by interface的成绩有点不堪入目，和很垃圾的Linq处于同一水准。
区别是什么，代码上看，仅仅是多了个类型的提示，但是对编译器而言，这个类型提示却影响了优化，编译器不再把data作为数组来优化，而是把它作为一个普通的实现IEnumerable<long>的对象来执行，在执行linq时，显然ms不会有空到为数组专门提供一套linq的实现，因此，对数组进行linq操作是，同样也是作为一个普通的IEnumerable<T>来执行的，因此，无比强大的编译器优化就没有了用武之地，所以性能自然而然的下降了很多。
最后
不过，不得不说明的是，虚方法（所有的接口方法都是虚方法）虽然有代价，但是通常情况下，这个几乎不可感知，这里只是因为这里的分式比较特殊：
(简单得不能再简单的数组操作代价+虚方法代价)/简单得不能再简单的数组操作代价
导致这个比例看起来比较夸张而已。
所以，还是请大家继续放心大胆的使用虚方法，当然遇到这样的诡异的性能问题时，也请想起这是不是因为虚方法的代价导致的幻觉