Is there ever a good reason to use Insertion Sort?

Question

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, i

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.