Is there ever a good reason to use Insertion Sort?

For general-purpose sorting, the answer appears to be no, as quick sort, merge sort and heap sort tend to perform better in the average- and worst-case scenarios. However, insertion sort appears to excel at incremental sorting, that is, adding elements to a list one at a time over an extended period of time while keeping the list sorted, especially if the insertion sort is implemented as a linked list (O(log n) average case vs. O(n)). However, a heap seems to be able to perform just (or nearly) as well for incremental sorting (adding or removing a single element from a heap has a worst-case scenario of O(log n)). So what exactly does insertion sort have to offer over other comparison-based sorting algorithms or heaps?

From http://www.sorting-algorithms.com/insertion-sort:

> Although it is one of the elementary sorting algorithms with > O(n²) worst-case time, insertion sort > is the algorithm of choice either when > the data is nearly sorted (because it > is adaptive) or when the problem size > is small (because it has low > overhead). >
> For these reasons, and because it is also stable, insertion sort is > often used as the recursive base case > (when the problem size is small) for > higher overhead divide-and-conquer > sorting algorithms, such as merge sort > or quick sort.

An important concept in analysis of algorithms is asymptotic analysis. In the case of two algorithms with different asymptotic running times, such as one O(n^2) and one O(nlogn) as is the case with insertion sort and quicksort respectively, it is not definite that one is faster than the other.

The important distinction with this sort of analysis is that for sufficiently large N, one algorithm will be faster than another. When analyzing an algorithm down to a term like O(nlogn), you drop constants. When realistically analyzing the running of an algorithm, those constants will be important only for situations of small n.

So what does this mean? That means for certain small n, some algorithms are faster. This article from EmbeddedGurus.net includes an interesting perspective on choosing different sorting algorithms in the case of a limited space (16k) and limited memory system. Of course, the article references only sorting a list of 20 integers, so larger orders of n is irrelevant. Shorter code and less memory consumption (as well as avoiding recursion) were ultimately more important decisions.

Insertion sort has low overhead, it can be written fairly succinctly, and it has several two key benefits: it is stable, and it has a fairly fast running case when the input is nearly sorted.

Yes, there is a reason to use either an insertion sort or one of its variants.

The sorting alternatives (quick sort, etc.) of the other answers here make the assumption that the data is already in memory and ready to go.

But if you are attempting to read in a large amount of data from a slower external source (say a hard drive), there is a large amount of time wasted as the bottleneck is clearly the data channel or the drive itself. It just cannot keep up with the CPU. A natural series of waits occur during any read. These waits are wasted CPU cycles unless you use them to sort as you go.

For instance, if you were to make your solution to this be the following:

1. Read a ton of data in a dedicated loop into memory
2. Sort that data

You would very likely take longer than if you did the following in two threads.

Thread A:

1. Read a datum
2. Place datum into FIFO queue
3. (Repeat until data exhausted from drive)

Thread B:

1. Get a datum from the FIFO queue
2. Insert it into the proper place in your sorted list
3. (repeat until queue empty AND Thread A says "done").

...the above will allow you to use the otherwise wasted time. Note: Thread B does not impede Thread A's progress.

By the time the data is fully read, it will have been sorted and ready for use.

Most sorting procedures will use quicksort and then insertion sort for very small data sets.

If you're talking about maintaining a sorted list, there is no advantage over some kind of tree, it's just slower.

Well, maybe it consumes less memory or is a simpler implementation.

Inserting into a sorted list will involve a scan, which means that each insert is O(n), therefore sorting n items becomes O(n^2)

Inserting into a container such as a balanced tree, is typically log(n), therefore the sort is O(n log(n)) which is of course better.

But for small lists it hardly makes any difference. You might use an insert sort if you have to write it yourself without any libraries, the lists are small and/or you don't care about performance.

YES,

Insertion sort is better than Quick Sort on short lists.

In fact an optimal Quick Sort has a size threshold that it stops at, and then the entire array is sorted by insertion sort over the threshold limits.

Also...

For maintaining a scoreboard, Binary Insertion Sort may be as good as it gets.

See this page.

For small array size insertion sort outperforms quicksort. Java 7 and Java 8 uses dual pivot quicksort to sort primitive data types. Dual pivot quicksort out performs typical single pivot quicksort. According to algorithm of dual pivot quicksort :

1. For small arrays (length < 27), use the Insertion sort algorithm.
2. Choose two pivot...........

Definitely, insertion sort out performs quicksort for smaller array size and that is why you switch to insertion sort for arrays of length less than 27. The reason could be: there are no recursions in insertion sort.

Source: http://codeblab.com/wp-content/uploads/2009/09/DualPivotQuicksort.pdf