Question

Results

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

listCopy.Sort(Comparer<int>.Default) takes 314ms.

Using

sealed class IntComparer : IComparer<int>
{
  public int Compare(int x, int y)
  {
    return x < y ? -1 : (x == y ? 0 : 1);
  }
}

listCopy.Sort(new IntComparer()) takes 716ms.

Some variations:

• Using struct IntComparer instead of sealed class: 771ms
• Using public int Compare(int x, int y) { return x.CompareTo(y); }: 809ms

Comments

Comparer<int>.Default returns a GenericComparer<int>. According to dotPeek, we have:

internal class GenericComparer<T> : Comparer<T> where T : IComparable<T>
{
  public override int Compare(T x, T y)
  {
    if ((object) x != null)
    {
      if ((object) y != null)
        return x.CompareTo(y);
      else
        return 1;
    }
    else
      return (object) y != null ? -1 : 0;
  }

...
}

Obviously, this shouldn’t be faster than my IntComparer variant using CompareTo.

I didn’t find anything relevant in ArraySortHelper<T>, which appears to be the core of List<T>.Sort.

I can only guess that the JIT does some magic special-casing here (Replace sorts which use Comparer<int>.Default by a specialized sorting implementation which doesn’t do any IComparer<T>.Compare calls, or something similar)?

EDIT: The timings above are too low by a factor of 5.9214729782462845 (Stopwatch and TimeSpan have a different definition of “Tick”). Doesn’t affect the point, though.

Answer 1

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.