Introduction

Enumerable.OrderBy in LINQ to Objects performs a stable sort, but the exact internal algorithm is not part of the public API contract. The important guarantees for application code are deferred execution, stable ordering, and support for chained keys through ThenBy.

If you are asking because of performance or correctness, the stable-sort behavior matters more than memorizing the current internal implementation. That said, the LINQ to Objects implementation is generally described as a QuickSort-style sort over buffered elements and computed keys.

What OrderBy Guarantees

The public contract of OrderBy is:

• it sorts by a key selector
• it is stable for equal keys
• it uses deferred execution until enumeration

Stability means that if two elements have equal keys, they remain in their original relative order unless another ordering stage changes that.

Example:

1using System;
2using System.Linq;
3
4var items = new[]
5{
6    new { Name = "A", Score = 10 },
7    new { Name = "B", Score = 10 },
8    new { Name = "C", Score = 5 }
9};
10
11var sorted = items.OrderBy(x => x.Score).ToList();
12
13foreach (var item in sorted)
14{
15    Console.WriteLine($"{item.Name} {item.Score}");
16}

The two items with score 10 stay in their original order relative to each other.

How LINQ To Objects Sorts In Practice

OrderBy does not sort lazily one comparison at a time from the original sequence. It first buffers the source sequence, computes the keys, and then sorts an index map according to those keys. That architecture supports stable sorting and efficient multi-key composition with ThenBy.

Conceptually, it looks like this:

1. enumerate the source into memory
2. compute key values
3. sort positions based on the keys
4. yield elements in sorted order

That means OrderBy is not appropriate for infinite sequences and is not a streaming sort. It needs the whole input.

The Internal Algorithm Detail

For LINQ to Objects, the implementation has long been described as QuickSort-like rather than something exotic such as Shellsort. It sorts using internal helper structures and preserves stability by incorporating original element positions into tie-breaking behavior.

The important caveat is that this is an implementation detail, not a promise the framework team must preserve forever. If a future .NET release changed the internal sorter while keeping the observable behavior the same, application code should still work.

So the best practical answer is:

• contract: stable ordered projection over buffered data
• implementation: currently QuickSort-style internals for LINQ to Objects

Why ThenBy Works So Well

Multi-key ordering is one of the nicest parts of LINQ sorting because the sorter composes key comparisons cleanly:

1var sorted = items
2    .OrderBy(x => x.Score)
3    .ThenBy(x => x.Name)
4    .ToList();

This works because the sorting infrastructure keeps earlier ordering decisions and adds later tie-breakers correctly. That is a stronger reason to understand OrderBy than the exact partitioning algorithm.

Performance Implications

In typical cases, you should think of OrderBy as O(n log n) time plus memory for buffering the sequence and its sort metadata. For most application code that is perfectly reasonable, but it matters when:

• the source sequence is very large
• the key selector is expensive
• repeated sorting happens in hot code paths

If the key selector is costly, projecting the key once inside OrderBy is usually better than recomputing it manually in custom comparisons.

Compare With List<T>.Sort

It is also worth separating Enumerable.OrderBy from List<T>.Sort. They are different APIs with different behaviors and constraints. List<T>.Sort sorts the list in place, while OrderBy builds a new ordered sequence view over buffered data. OrderBy is stable. In-place sort behavior elsewhere in .NET is not the same design question.

That is why asking "what algorithm does LINQ use" is not exactly the same as asking "what algorithm does .NET use for all sorting."

Common Pitfalls

One common mistake is assuming OrderBy streams results without buffering. It does not. Another is relying on an internal algorithm detail as if it were a framework guarantee. Developers also often compare OrderBy and List<T>.Sort as though they were interchangeable, even though one is a LINQ sequence operator and the other is an in-place list method. Finally, many performance discussions focus too much on the algorithm name and too little on the fact that key extraction, allocation, and buffering often dominate real application cost.

Summary

• 'OrderBy guarantees a stable sort with deferred execution until enumeration.'
• LINQ to Objects buffers the sequence and sorts based on computed keys.
• The internal implementation is QuickSort-like, but that is not a public contract.
• 'ThenBy works because the ordering infrastructure composes key comparisons cleanly.'
• For application code, stable behavior and buffering costs matter more than the exact internal sorter name.