How does size of list in merge-sort, quick-sort, insertion-sort, matter?
It's unclear to me why you put the algorithms in that order. Also, &quot;best work&quot; is quite informal. There are many ways to compare sorting algorithm (worst-case time, expected-time, space complexity, etc). Some considerations that might help you are below.
I can see how InsertionSort could be faster than MergeSort of QuickSort in practice for small lists.
The worst-case complexity of InsertionSort can be upper bounded by $c n^2$ for some constant $c$, while the worst-case (resp. expected) complexity of quicksort can be lower bounded by $c' n \log n$ for some $c'$. It might very well be that the multiplicative constant $c'$ is large enough to satisfy $c n^2 &lt; c' n\log n$ for small $n$.
For huge lists, a &quot;standard&quot; implementation of merge sort requires $O(n)$ auxiliary space, while quick-sort can be run in place. They both have the same asymptotic expected running time, so if that's how you are comparing your algorithms, QuickSort might be preferred.
If you're comparing the algorithms by their worst case running time then it might be the case (I didn't estimate the actual constant, which depends on the specific implementation anyway) that QuickSort runs in time $\approx c_q n^2$ while MergeSort runs in time $\approx  c_m n \log n$. In this case MergeSort is clearly preferred for large enough list but, if  $c_q \ll c_m$, QuickSort would be preferred for moderately-sized lists.
Notice that, in practice, you can just use QuickSort (since the extra overhead spent for small lists in negligible, in the absolute sense). Fancy implementations (such as the ones often found in standard libraries) use hybrid algorithms: they run QuickSort and if they realize that the size of the subproblems is somehow not shrinking fast enough, they revert to MergeSort. Whenever the number of elements left to sort is small, they switch to a quadratic-time sorting algorithm like InsertionSort.