Having a sorted list can make all sorts of operations easier. Developing or maintaining that structure can have a high time complexity. This article briefly explains and also explores two philosophies to sorting, v differing performance.

You are watching: When is insertion sort better than merge sort

Code instances for both sorts and comparing them can be found here, here and also here.

The Data

In both of these algorithms, we’ll be managing a Python perform of numbers. There space three species of data we’ll run with the algorithms, practically sorted (two items the end of place), reverse sorted (descending, when we want ascending) and also random. We’ll use an increasing size of perform (n), to show the power of both algorithms as the lot of data scales up.

Insertion Sort

Insertion sort appears to “grow” the sorted data native the beginning of the array. This algorithm starts at the start of one array, sorting aspects as the encounters them; to start with, key = 0.

Work through the element at position key. The existing position the the aspect at key will constantly be save in a different variable, i.If there is an facet at i - 1 and also it is larger, then swap them. If the elements were swapped, decrement i to keep track of where the aspect now sit in the array. Repeat this step until the facet at i is greater than or equal to the at i - 1, or i = 0.Increment key and return to action 1. This ensures that the next unsorted element is now functioned on.

Insertion sort provides a lot of comparisons, it additionally only swaps elements when it’s required. In an already sorted list, the only work-related this algorithm go is comparisons.

Merge Sort

Merge sorting involves recursively splitting a perform of data into halves, till each aspect sits in its own one element list; this is the basic case. Every level of calls climate compares 2 lists, making use of a “merge” to incorporate the two into a solitary sorted list.

The merge takes two sorted perform of numbers, A and B, i beg your pardon are combined into one sorted list C. To begin with, the algorithm would be feather at 2 one-element A and B perform (from the base case). That keeps track of development through A and B, using counters i and j respectively.

Set i and j to 0.Compare A<i> and B<j>, append the smaller of the 2 onto **C **(pick one of two people if they’re equal).Increment i if the aspect appended to C come from A, increment j if the facet came from B.Repeat steps 2 and 3 until every one of either A or B has been appended top top to C, this perform is now “exhausted”.Append all the remaining aspects from the list that was no exhausted, ~ above C.C is currently a sorted list of elements that are current in A and B. Return C come the calling function, i beg your pardon will also receive an additional sorted list and start from action 1.

Merge sort goes with this procedure regardless of just how sorted the data currently is; if you passed it a totally sorted list, it would still do all the recursive calls, execute all the to compare between A’s and B’s, and make C’s. Just how much work merge type does, is thus only connected to the dimension of perform it operates on.

For those wanting more detail and also a graphics depiction of unify sort, the merge type code example was based upon this explanation.

Differing Performance

The different approaches to sorting data in this algorithms, produce some effects worth noting. Turbulent timings for various data are available in the comments here, if you’d prefer to view where these comparisons room coming from.

With minimal information, it would be simple to come under on the side of one of two people of these algorithms being “better” 보다 the other. The information I’ve offered above, around when every does work, could suggest that insertion type is better. Vice versa, those acquainted with huge O notation, might jump come the conclusion that merge sort is better (worst case merge kind is n log n, insertion is n²). However, just like so numerous things, it’s not constantly that clean cut and also will depend on the particular application.

For constant n, merge type is more consistent in the performance 보다 insertion sort. This is because of it taking the same path to sorting the data, regardless of exactly how sorted the entry is; for all 3 kinds that data tested, the sorted the biggest n in about 10s.

Also because that constant n, the power of insertion sort varies wildly, because it is dependent on how sorted the input was. In ~ a data size of 20,480 insertion type finished in 0.007s (almost sorted), 27s (random) and also 69s (reversed). If one application requirements to frequently sort random or reversed data, climate merge kind would it is in a far better choice.

This is specifically true if the application have to also attend to a big variance in n. Insertion type performance deteriorates rapidly in worst cases, i beg your pardon is where the big O complexity comes in. For reversed data, doubling n from 10,240 to 20,480 quadrupled processing time from 17s come 69s. Merge type performance doubled because that the same boost of n, yet only to 0.1s. If the data because that an application is change in both size and arrangement, merge kind is walking to carry out consistent and also pretty scalable performance.

In brute pressure comparisons on arbitrarily data, merge kind will constantly outperform insertion sort as n grows. However, it’s not an overwhelming to photo a situation where one application needs to maintain a sorted list; rather than create one from random data each time. In instances where the worths in a sorted list have altered really little, insertion sort have the right to out perform merge sort. On the biggest “almost sorted” data (two facets out that place), insertion sort finished in 0.4s compared to unify sort’s continual ~10s. In this case, one application could initially usage a unify sort, adhered to by insertion kind as the perform values room incrementally updated.

See more: Ever Wondered: Where Do Praying Mantis Go In Winter ? Praying Mantis Fact Sheet & Release Instructions


There’s an dreadful lot more that could be said around both of these algorithms, including lots of various structures of data and little variations in the code itself. Indigenous this quick explanation though, it should already be clear that understanding your application/data well enough to pick the right solution, is wiser than advertising one algorithm the best in every cases.