Sorting and Efficiency

This SLOG entry is about sorting and efficiency.
The first time I encountered the topic of efficiency was in last semester's CSC165. We were taught how to read a piece of code and write a proof for its big Oh, big theta, and big omega.
The first time I encoutered sorting was in CSC108, where we learnt about bubble sort, selection sort, and insertion sort.

In CSC148, we looked at the following types of sorting.
First was select sort, where the minimum value of the remainder of the list is constantly found and switched with the item at index i, which is the starting index of what we define as the remainder. Then we define the remainder to start at index i + 1, until we reach the end of the list. This way the worst case is when the minimum value is always at the end of the remainder list, where for a list of length n, to find the minimum value we will have to search through n items, the n - 1 items, then n - 2 items. Added together, selection sort will have a big oh of n (O(n))
Then we looked at quick sort, which is a recursive function that takes an index i, and calls quick sort on a list of values smaller than the one at index i, and calls quick sort on a list of values bigger or equal (excluding L[i]) to the one at index i, then puts the two lists and value L[i] together in order. The big oh will be O(n) since to find the values smaller or larger to value L[i], the whole list of n values will have to be searched through.
Then we looked at merge sort, which also calls on function merge. Function merge takes two sorted lists and adds items into a new list in order. Merge is O(n), where n is the bigger length of L1 and L2. Therefore merge sort's worst case runtime is n/2 + n/2, which is still n.
Although for all of the above, the big Oh is n. This doesn't tell everything about efficiency. By testing on a list of 10000 objects, selection sort took the most time.