Efficiency of Merge sort (nlogn) is always faster then Selection sort (n^2). When would you ever choose selection over merge sort?

- 362,284
- 104
- 897
- 1,065

- 23
- 1
- 3
-
You would rarely choose either, there are better general purpose sorting algorithms. – Zabuzard Apr 23 '20 at 18:16
-
@Zabuza But the real question is why you would choose an O(n^2) algorithm over an O(n log n) algorithm. And if Merge and Selection are the only ones you have available . . . – Jim Mischel Apr 24 '20 at 14:02
-
see also https://stackoverflow.com/a/19639780/56778 – Jim Mischel Apr 24 '20 at 14:04
-
For sure, that is why I posted this as a comment only. – Zabuzard Apr 24 '20 at 15:03
1 Answers
Because the runtime of selection sort is Θ(n2) and the runtime of mergesort is O(n log n), for sufficiently large inputs mergesort will outperform selection sort. However, there are two areas in which selection sort might be better:
Selection sort on an array can be implemented with O(1) auxiliary storage space, whereas (most) implementations of mergesort on arrays use Θ(n) auxiliary storage space. As a result, if memory is extremely scarce, selection sort would be a better choice than mergesort. (However, it would be a worse choice than, say, heapsort or quicksort!)
Selection sort may be faster than mergesort on small input arrays because it's a simpler algorithm with lower constant factors than the ones hidden by mergesort. If you're sorting, say, arrays of 16 or so elements, then selection sort might be faster than mergesort. (However, it would probably be a worse choice than, say, insertion sort).
So in other words, there are some cases where selection sort would be better than mergesort, but in those cases you're still probably better off using another sorting algorithm. :-)

- 362,284
- 104
- 897
- 1,065