+ * The 'ranks' array essentially captures the recursion stack of a mergesort.
+ * The merge tree is built in a bottom-up manner. The control loop for
+ * updating the 'ranks' array is analogous to incrementing a binary integer,
+ * and the O(n) time for counting upto n translates to O(n) merges when
+ * inserting rank-0 lists. When we plug in the sizes of the lists involved in
+ * those merges, we get the O(n log n) time for the sort.
+ *
+ * Inserting higher-ranked lists reduce the height of the merge tree, and also
+ * eliminate a lot of redundant comparisons when merging two lists that would've
+ * been part of the same run. Adding a rank-i list is analogous to incrementing
+ * a binary integer by 2**i in one operation, thus sharing a similar speedup.
+ *
+ * When inserting higher-ranked lists, we choose to clear out the lower ranks
+ * in the interests of keeping the sort stable, but this makes analysis harder.
+ * Note that clearing the lower-ranked lists is O(length(list))-- thus it
+ * shouldn't affect the O(n log n) behaviour. IOW, inserting one rank-i list
+ * is equivalent to inserting 2**i rank-0 lists, thus even if we do i additional
+ * merges in the clearing-out (taking at most 2**i time) we are still fine.