Because in order to decide which is best, you need some criteria for success. You also need to consider the application and hardware. E.g. if sorting 16-bit o

Because in order to decide which is best, you need some criteria for success. You also need to consider the application and hardware. E.g. if sorting 16-bit or smaller integers, the best algorithm is to build a histogram in a single pass, then expand it again. That's assuming PC/laptop/smartphone hardware, if you are programming a microcontroller you may not have enough memory available. Some applications want sorting to be a one-shot deal. Other applications want a dynamic data structure that maintains sorted order -- this is the binary tree. If the things you are sorting are very large and hence stored on disk instead of in memory, you may remember that disk hardware must fetch a whole sector to fetch one byte, having larger tree nodes can be a win because you gain when it makes the tree flatter, but the loss you pay doesn't matter because when reading a anything from the disk, you get the whole sector it's in for no additional cost. These are called B-trees and are very popular in database implementations. If your hardware architecture demands the indices of the things you're comparing must be fixed (i.e. you're not allowed to use the data to decide which array slots need to be compared), you want a sorting network. This applies to designing sorting hardware, and is also used in programming sorts on GPU's. At least one other poster's noted that caches on modern hardware give mergesort a strong advantage over quicksort.