数组排序方法的性能比较（3）：LINQ排序实现分析
2010-01-27 00:02 by 老赵, 10037 visits上次我们分析了Array.Sort<T>方法的实现方式，并了解到类库会为一些特例而使用高性能的排序方式——int数组便是这样一例，因此从测试结果上来看其性能特别高。不过从数据上看，即便是在普通的情况下，Array.Sort<T>的性能也比LINQ排序要高。不过也有朋友从测试中得出的结论正好相反，这又是为什么呢？那么现在，我们再来分析一下LINQ排序的实现方式吧，希望这样可以了解到两者性能差别的秘密。
只可惜，LINQ排序的代码在System.Core.dll程序集中，微软没有发布这部分源代码，我们只得使用.NET Reflector来一探究竟了。
LINQ排序接口的定义、使用及扩展
所谓LINQ排序，便是使用定义在System.Linq.Enumerable类中的几个扩展方法，它们是：
public static IOrderedEnumerable<TSource> OrderBy<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector); public static IOrderedEnumerable<TSource> OrderBy<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector, IComparer<TKey> comparer); public static IOrderedEnumerable<TSource> OrderByDescending<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector); public static IOrderedEnumerable<TSource> OrderByDescending<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector, IComparer<TKey> comparer);
为了使用时的方便，我往往会补充一些额外的接口，例如：
public static IOrderedEnumerable<TSource> OrderBy<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector, bool decending) { return decending ? source.OrderByDescending(keySelector) : source.OrderBy(keySelector); }
这样在使用时，便可以使用一个布尔值来表示排序的方向（升序或是降序）而不需要从两个方法之间“手动”选择一个。此外，构造一个IComparer<TKey>类型也实在有些麻烦，于是我按照Array.Sort<T>的做法重新继续扩展了一个使用委托对象作为“比较器”的接口：
public static IOrderedEnumerable<TSource> OrderBy<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector, Comparison<TKey> compare, bool decending) { return decending ? source.OrderByDescending(keySelector, new FunctorComparer<TKey>(compare)) : source.OrderBy(keySelector, new FunctorComparer<TKey>(compare)); }
至于FunctorComparer类的实现，由于过于简单就省略了吧，贴出来也只是占用地方而已。有了这个接口，在排序的时候我们就可以这样使用了：
employee.OrderBy(p => p.Manager, (m1, m2) => ... /* 比较逻辑 */, false);
不过，无论是哪个接口、重载还是扩展，它的（除this外）的第一个参数便是keySelector，它的含义便是选择（select）出排序的“依据”。这个参数不可省略（除非您提供扩展），因此即便是int数组这样的类型，需要排序时也必须指定“自己”为排序依据：
intArray.OrderBy(i => i);
这也是LINQ排序和Array.Sort<T>的本质区别之一。
OrderedEnumerable的实现
无论是哪个接口，最终创建的都是OrderedEnumerable<TElement, TKey>类型，例如：
public static IOrderedEnumerable<TSource> OrderBy<TSource, TKey>( this IEnumerable<TSource> source, Func<TSource, TKey> keySelector) { return new OrderedEnumerable<TSource, TKey>(source, keySelector, null, false); }
OrderedEnumerable<TElement, TKey>的含义是“根据TKey排序TElement序列的结果”，它的构造函数仅仅是保留传入的参数：
internal OrderedEnumerable( IEnumerable<TElement> source, Func<TElement, TKey> keySelector, IComparer<TKey> comparer, bool descending) { // 省略参数校验 base.source = source; this.parent = null; this.keySelector = keySelector; this.comparer = (comparer != null) ? comparer : ((IComparer<TKey>) Comparer<TKey>.Default); this.descending = descending; }
可见，如果您没有提供比较器，类库会自动选用Comparer<TKey>.Default进行比较。这个类会尽可能地寻找可用的比较方式，在“万不得已”的情况下只得跑出异常。如果您对它的实现感兴趣可以自行阅读代码——甚至无需使用.NET Reflector。
事实上，在OrderedEnumerable<TElement, TKey>中并没有提供排序等关键性功能，它只是override了基类的GetEnumerableSorter方法，用于提供一个“排序器”。它的基类是OrderdEnumerable<TElement>，其含义是“排序TElement序列的结果”，它并不涉及到“排序方式”，而只是提供了一个抽象方法用于获得一个“排序器”——没错，这就是它的子类，如OrderedEnumerable<TElement, TKey>的职责了（还记得TKey的含义吗：“根据TKey进行排序”）。
不过，事实上除了OrderdEnumerable<TElement, TKey>以外也没有其他子类了，由于这些都是internal类型，因此我认为这样有些“过渡设计”。根据我们昨天“人肉反编译”的结果，可以得到OrderedEnumerable<TElement>的完整实现：
internal abstract class OrderedEnumerable<TElement> : IEnumerable<TElement>... { internal IEnumerable<TElement> source; internal abstract EnumerableSorter<TElement> GetEnumerableSorter(EnumerableSorter<TElement> next); public IEnumerator<TElement> GetEnumerator() { var buffer = new Buffer<TElement>(this.source); if (buffer.count <= 0) yield break; var sorter = this.GetEnumerableSorter(null); var map = sorter.Sort(buffer.items, buffer.count); for (var i = 0; i < buffer.count; i++) { yield return buffer.items[map[i]]; } } ... }
与我们平时接触到的排序算法不同，EnumerableSorter的Sort方法并不改变原数组，它只是生成根据buffer.items数组生成一个排序之后的“下标序列”——即map数组。当外部需要输出排序后的序列时，OrderedEnumerable<TElement>才会根据map中的下标顺序，依次输出buffer.items数组中的元素。
请注意，到目前为止我们还是没有接触到最终的排序实现。换句话说，现在我们还是不清楚LINQ排序性能高（或低）的关键。
排序实现：EnumerableSorter
LINQ排序的实现关键还是在于EnumerableSorter<TElement>，我们且看其Sort代码：
internal abstract class EnumerableSorter<TElement> { internal abstract int CompareKeys(int index1, int index2); internal abstract void ComputeKeys(TElement[] elements, int count); private void QuickSort(int[] map, int left, int right) { ... } internal int[] Sort(TElement[] elements, int count) { this.ComputeKeys(elements, count); int[] map = new int[count]; for (int i = 0; i < count; i++) { map[i] = i; } this.QuickSort(map, 0, count - 1); return map; } }
从之前的分析中得知，Sort方法的作用是返回一个排好序的下标数组。它会调用ComputeKeys抽象方法“事先”进行Key（也就是排序依据）的计算。然后再使用快速排序来排序map数组。在QuickSort中，它使用CompareKeys方法来获得“两个下标”所对应的元素的先后顺序。仅此而已，没什么特别的。甚至我在这里都不打算分析ComputeKeys和CompareKeys两个方法的实现，因为他们实在过于直接：前者会把source序列中的元素依次调用keySelector委托，以此获得一个与source对应的TKey数组，而后者便是根据传入的下标来比较TKey数组中对应的两个元素的大小。
不过，我还是强烈建议您阅读一下EnumerableSorter<TElement>及其子类EnumerableSorter<TElement, TKey>的实现，以此了解LINQ to Object是如何优雅地支持以下表达式的：
var sorted = from p in people orderby p.Age orderby p.ID descending select p;
这个表达式的含义是“将Person序列首先根据Age属性进行升序排列，如果Age相同则再根据ID降序排”——类库在实现时使用了类似于“职责链模式”的做法，颇为美观。
LINQ排序与Array.Sort<T>的性能比较
如果您仔细阅读EnuerableSorter的QuickSort方法，会发现它使用的快速排序算法并不“标准”。快速排序的性能关键之一是选择合适的pivot元素，但是QuickSort方法总是选择最中间的元素——(left + right) / 2。此外，它也没有在元素小于一定阈值时使用更高效的插入排序。因此，从理论上来说，QuickSort方法使用的快速排序算法，其性能不如Array.Sort<T>。
不过，根据姜敏兄的测试结果，LINQ排序的性能超过Array.Sort<T>，这又是怎么回事呢？事实上，虽然姜兄的这个测试存在很大的问题（代码写错了），最后得到的结论“性能高低和元素类型有关”的结论也不确切，但是它也的确能体现一些问题。这个问题事实上已经由Ivony...老大解释过了，不过为了信息完整思维连贯，我在这里再进行详细说明一下。
从理论上来说，Array.Sort<T>和LINQ排序的时间复杂度是相同的，因此性能“似乎不会有太大不同”，但是从实验结果上看差距还是十分明显的。因为从实际上看，Array.Sort<T>对于特殊类型有特殊处理，此外LINQ排序会有复制元素的开销，因此我之前我认为“找不到LINQ排序的性能有优势的理由”。可惜这句话已经站不住脚了，我们来观察一下两种排序方式在实现上的主要区别：
- Array.Sort<T>：使用IComparer<T>对象比较两个元素的大小。
- LINQ排序：首先根据keySelector获得TKey序列，然后在排序时使用IComparer<TKey>比较两个TKey元素的大小。
那么，以此您是否可以判断出以下两个排序方法的性能高低？
public class Person { public int Age { get; set; } } public class PersonComparer : IComparer<Person> { public int Compare(Person x, Person y) { return x.Age - y.Age; } }
Person[] people = ... var byLinq = people.OrderBy(p => p.Age).ToList(); var byArray = Array.Sort(people, new PersonComparer());
在实际测试之前我无法做出判断，因为它们其实各有千秋：
- Array.Sort<T>：虽然不需要进行额外的元素复制，但是调用PersonComparer.Compare方法的开销较大——访问Age属性相当于调用get_Age方法（如果没有内联的话——不过从实际结果看的确被内联了）。
- LINQ排序：虽然需要进行额外的元素复制，而且需要事先计算出排序用的键值（Age属性），但是在排序时只需直接比较int即可，效率较高。
这其实也就是某些测试中发现LINQ排序性能较高的“秘密”。为什么同样排序Person序列时，我的测试（http://gist.github.com/282796）表明Array.Sort<T>较快，而其他一些朋友却得到LINQ排序较快的结果呢？这是因为我的Person类直接使用了公开字段而不是属性，这样避免了方法调用的开销（因为有内联，这点应该不是问题）。此外，另一些朋友的PersonComparer在比较两个int时使用了x.Age.CompareTo方法——这又比直接进行int减法要慢上一些了。
那么，还有影响两者性能的因素吗？我们有办法提高数组排序的性能吗？毕竟很多时候我们需要直接排序，而不是生成新的序列。下次我们再来讨论这些问题吧。
相关文章
- 数组排序方法的性能比较（1）：注意事项及试验
- 数组排序方法的性能比较（2）：Array.Sort<T>实现分析
- 数组排序方法的性能比较（3）：LINQ排序实现分析
- 数组排序方法的性能比较（4）：LINQ方式的Array排序
- 数组排序方法的性能比较（5）：对象大小与排序性能
有些细节描述好像不太对。一般调用getter都是被内联掉了的。CLRv2对小的、直线型、非虚方法会很“照顾”，如果是在循环中调用这样的方法会更加“照顾”。而自动生成的getter里就是一个成员变量访问+一个返回，除非作为某个基类型的虚属性的override实现，或者被打上了noinline标记，不然肯定是被内联的。
using System; using System.Runtime.CompilerServices; namespace TestCLRv2JITInlinePropertyAccess { public class Person { public int _age; public int Age { get { return _age; } set { _age = value; } } } static class Program { [MethodImpl(MethodImplOptions.NoInlining)] static int Foo(Person p) { return p.Age; } [MethodImpl(MethodImplOptions.NoInlining)] static int Bar(Person p) { return p._age; } static void Main(string[] args) { var p = new Person(); Console.WriteLine(p.Age); Foo(p); Bar(p); } } }这里的Foo和Bar分别是：
是一样的对吧？