The time complexity of algorithms is given in Big-O notation, the time that asymptotically bounds the average case run time. The best comparative sorting algorithms run in n log n time, while more naive sorts run in n^2 time, though some impractical sorts may take unboundedly long.  Generally, the built-in sorting algorithm for most languages is an optimized quicksort, that uses insertion sort for small values of n.  Some languages, like Python and Java, use a tuned mergesort (java for arrays of objects, not prims).  There are also non-comparative sorts, like radix sort and counting sort, that run in non-polynomial time (n*k, n+ry) and do not compare the values of the list being sorted.  The defining similarity of comparative sorts is that they compare values, to see which is smaller.  When sorting algorithms are being analysed, their time complexity is basically an analysis of how many times numbers are compared.  Slow algorithms like bubble sort might need to compare values and swap array positions up to n^2 times, whereas better sorts like mergesort and quicksort only need to compare n log n times.  While most of the time a fast sort that runs in n log n time will be sufficient for practical applications, other considerations, like the size of n, the worst-case run time of the algorithm, the memory complexity of the algorithm, and the stability of the algorithm, become important considerations with specific applications.  Knowing how to code a practical and efficient sorting algorithm is an important basic skill for all programmers, but similar to coding your own priority queue, becomes superfluous is most languages where such things are built into the standard library.