MergeSort is a divide-and-conquer algorithm that divides the input into several parts and solves the parts recursively.

...There are several approaches for the split function. One way is to split down the middle. That approach has some nice properties, however, we'll focus on a method that's a little bit faster: even-odd split. The idea is to put every even-position element in one list, and every odd-position in another.

This is straight from my lecture notes. Why exactly is it the case that the even-odd split is faster than down the middle of the array?

I'm speculating it has something to do with the list being passed into MergeSort and having the quality of already sorted, but I'm not entirely sure.

Could anyone shed some light on this?

  • $\begingroup$ the improvement seems to be justified if the list to be sorted is too long to fit in memory at a time. Carrying out some experiments might help. $\endgroup$
    – singhsumit
    May 25, 2011 at 16:18
  • 1
    $\begingroup$ Take a look at these slides: faculty.cs.byu.edu/~ringger/Winter2006-CS312/lectures/…. $\endgroup$ May 25, 2011 at 16:45
  • 3
    $\begingroup$ The assumption may be that you have a linked list, so to split down the middle requires walking the list once to get its length and then the first half again. $\endgroup$ May 25, 2011 at 17:32
  • 5
    $\begingroup$ To follow up on @Aaron's answer, see en.wikipedia.org/wiki/Batcher_odd-even_mergesort . In normal sequential execution, an even-odd split isn't faster—merging takes Θ(n) time either way—but it can be more easily parallelized. $\endgroup$
    – Jeffε
    May 27, 2011 at 2:53
  • $\begingroup$ Is it parallelism or caching which makes the even-odd split faster? $\endgroup$ Jun 26, 2011 at 17:13

1 Answer 1


Looking at the graphing network on Wikipedia and this page for even-odd merge sort it appears that it has a higher complexity than traditional merge-sort. However, at the cost of more operations, notice how the operations remain independent of one another.

That is to say, where as in merge sort you eventually end up merging 4 lists and then 2 lists, which cannot be done in parallel, even-odd merge sort allows you to operate in parallel until the end of the algorithm.

The Wikipedia article also points out that it is reasonably fast for doing sort in graphics hardware. I suspect this is because where as merge sort your inputs to compare-and-swap depend on which previous element was merged, the inputs to compare-and-swap in even-odd-merge-sort are always the same.

Hope that helps!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.