Performance of the Java sorting algorithm

Generally, Java's standard sorting method (Arrays.sort() and its derivative Collections.sort()) does what you would expect from a library routine: it is general-purpose, correct, well-tested and provides adequate performance in many cases. The purpose of this page is therefore not to advocate that everyone goes off and writes their own sorting routine. However, sometimes it is useful to know what performance you can expect from the library routine, and what the few specialised cases are where it's worth replacing it.

Java's sorting algorithm

The sorting algorithm used (in Sun's implementation at least) is a version of mergesort¹. Mergesort is based on a "divide and conquer" strategy: we recursively divide the list into two halves and sort each half, then merge the two sorted halves back together. As we break the data down into smaller and smaller parts, we eventually reach a critical size where it's not worth dividing any more, and we sort in situ. Java uses an insertion sort for these 'atomic' sorts. Together, this gives Java's sort routine the following characteristics:

The sort is stable: i.e. if two elements are equal, their order won't be swapped after sorting (with some other algorithms, the order of equal elements is effectively random).
Because of the requirement to merge lists together into a new list, the algorithm operates on a copy of the data: when you call Arrays.sort(), the first thing the method does is take a clone of the array. Taking a clone of the array means taking a copy of the list of references, not of the actual data. The cost is generally negligible for large-ish arrays, but relatively considerable for sorting very small sets of data.
The underlying insertion sort has a worst case where the input data is in reverse order; thus in principle, it is possible to hit an unlucky case consisting of a series of sub-lists in reverse order.
In terms of recursion, this hybrid algorithm improves on some "textbook" cases of recursing right down until the sublist size is 1 or 2 (but at the expense of a less constant sort time as mentioned in the previous point).
In most practical cases, doubling the size of the list more or less doubles² the time taken to sort.

You might have read the last point and thought "well, duh!". But it turns out that more-or-less doubling the sort time as the data size is doubled is actually good going. Various less efficient sorting algorithms (including the insertion sort on its own) don't manage this, or are more likely to hit "worse cases", where the time effectively quadruples as the list size doubles.

Sort performance in practice

1. I understand that a different algorithm will be used in Java 7. Even more reason not to rewrite your code on the basis of the particular algorithm used in today's version of the library.
2. As we'll see, mergesort is usually analysed as an O n log n sort. In practical terms, this means that when we double the number of elements, the sort time is actually "slightly worse than double" (multiplying by 2.2 gives a good guide in many cases).

Written by Neil Coffey. Copyright © Javamex UK 2012. All rights reserved. If you have any feedback on the Java collections tutorials in this section or about the content of this site in general, please leave a message on the Javamex forum.