起因昨天看到了一篇文章，说到并行库的效率问题，在最后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
private static long MySum(IEnumerable
{
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
sum += item;
w.Stop();
Console.WriteLine("Foreach Sum (by interface):{0}", w.ElapsedMilliseconds);
}
与前面的ForEach的区别仅仅是显式的指明data的类型是IEnumerable
PLinq Sum:322 Linq Sum:597 For Sum:204 Foreach Sum:89 Foreach Sum (by interface):546 ForEach的成绩依然遥遥领先，但是ForEach by interface的成绩有点不堪入目，和很垃圾的Linq处于同一水准。
区别是什么，代码上看，仅仅是多了个类型的提示，但是对编译器而言，这个类型提示却影响了优化，编译器不再把data作为数组来优化，而是把它作为一个普通的实现IEnumerable
最后不过，不得不说明的是，虚方法（所有的接口方法都是虚方法）虽然有代价，但是通常情况下，这个几乎不可感知，这里只是因为这里的分式比较特殊：
(简单得不能再简单的数组操作代价+虚方法代价)/简单得不能再简单的数组操作代价
导致这个比例看起来比较夸张而已。
所以，还是请大家继续放心大胆的使用虚方法，当然遇到这样的诡异的性能问题时，也请想起这是不是因为虚方法的代价导致的幻觉
最新评论