Why is List.Sort using Comparer.Default more than twice as fast as an equivalent custom comparer?

Question

Results

Using a list of 10 million random ints (same seed each time, average of 10 repetitions):

listCopy.Sort(Comparer.Defau

Answer 1

ILSpy decompiles thus:

    public override int Compare(T x, T y)
    {
        if (x != null)
        {
            if (y != null)
            {
                return x.CompareTo(y);
            }
            return 1;
        }
        else
        {
            if (y != null)
            {
                return -1;
            }
            return 0;
        }
    }

The null checks will always evaluate as true for a value type, so they will be optimized away; the end result will be

public override int Compare(T x, T y)
{
    return x.CompareTo(y);
}

Answer 2

The default comparer for Int32 is the CompareTo(int,int) method. Your assumption of the default comparer is incorrect.

The IComparable interface provides a strongly typed comparison method for ordering members of a generic collection object. Because of this, it is usually not called directly from developer code. Instead, it is called automatically by methods such as List.Sort() and Add.

http://msdn.microsoft.com/en-us/library/4d7sx9hd.aspx. The IComparable interface mentioned defines the CompareTo method.

So we should expect your comparer to be about the same speed. So why might it be slower? If we dig down into the Sort method in .Net, we eventually get to this line:

if ((length > 1) && (((comparer != null) && (comparer != Comparer<T>.Default)) || !TrySZSort(array, null, index, (index + length) - 1)))
{
    ArraySortHelper<T>.Default.Sort(array, index, length, comparer);
}

If the comparer equals the default comparer for that type, the Array Sort will try to use an internal optimized sort method. Your comparer is not the default comparer, so it skips that optimized sort.

Answer 3

The reason is readily visible in the Reference Source, system/array.cs source code file:

   [ReliabilityContract(Consistency.MayCorruptInstance, Cer.MayFail)]
   public static void Sort<T>(T[] array, int index, int length, System.Collections.Generic.IComparer<T> comparer) {
       // Argument checking code omitted
       //...

       if (length > 1) {
           // <STRIP>
           // TrySZSort is still faster than the generic implementation.
           // The reason is Int32.CompareTo is still expensive than just using "<" or ">".
           // </STRIP>
           if ( comparer == null || comparer == Comparer<T>.Default ) {
               if(TrySZSort(array, null, index, index + length - 1)) {
                   return;
               }
           }

           ArraySortHelper<T>.Default.Sort(array, index, length, comparer);
       }
   }

The comment marked by <STRIP> explains it, in spite of its broken English :) The code path for the default comparer goes through TrySZSort(), a function that's implemented in the CLR and written in C++. You can get its source code from SSCLI20, it is implemented in clr/src/vm/comarrayhelpers.cpp. It uses a template class method named ArrayHelpers<T>::QuickSort().

It gets the speed advantage from being able to use the < operator, a single cpu instruction instead of the 10 required by Int32.CompareTo(). Or in other words, IComparable<>.CompareTo is over-specified for simple sorting.

It is a micro-optimization, the .NET Framework has lots and lots of them. The inevitable fate of code that sits at the very bottom of a dependency chain, Microsoft can never assume that their code isn't going to be speed-critical in a customer's app.