虚方法的代价

起因

    昨天看到了一篇文章，说到并行库的效率问题，在最后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>来执行的，因此，无比强大的编译器优化就没有了用武之地，所以性能自然而然的下降了很多。

最后

    不过，不得不说明的是，虚方法（所有的接口方法都是虚方法）虽然有代价，但是通常情况下，这个几乎不可感知，这里只是因为这里的分式比较特殊：

(简单得不能再简单的数组操作代价+虚方法代价)/简单得不能再简单的数组操作代价

    导致这个比例看起来比较夸张而已。

    所以，还是请大家继续放心大胆的使用虚方法，当然遇到这样的诡异的性能问题时，也请想起这是不是因为虚方法的代价导致的幻觉