Sorting with TreeMap vs. quicksort

Question

I've been sorting lists by throwing them into a TreeMap then retrieving them in order (especially for fairly evenly distributed lists of strings), thereby leveraging its binary tree characteristics.
My belief is that sorting this way takes N log N time, just as quicksort (as in Arrays.sort) does -- because adding items to a TreeMap takes log N time -- without any danger of stack overflows from recursing on a huge list as with quicksort, and fewer method calls which can get expensive.
I'm figuring that even if this way of sorting uses more memory than an in-place sort as in Arrays.sort, at least it won't overflow the stack, and will mostly be eligible for garbage collection anyway.
Could someone correct or confirm my conclusions, reasoning or assumptions? And how well do they apply to Collections.sort's merge sort?

Answer 1

Using a tree guarentees worst case O(n log n) for n
inserts.Amazing, my untrained intuition was correct.
As for stack problems these are unlikely to occur until
logn is at least a few thousand (think about stupidly large values of
n).I regularly need to sort lists of tends of thousands of strings.
.. its [quicksort's] gotcha is that
performance can degrade well below this approaching
O(n^2) (might be higher. I cant remember).Yes, O(n^2) for adversarial data. Does mergesort require a shallower recursion than quicksort does?
Since temporary use of the heap is rarely a concern for me, and datasets are very large, it sounds like mergesort and the TreeMap are viable contenders for preferred sorting methods. But I'm still apprehensive about mergesort's use of recursion.
Thank you, I gave you 5 duke dollars and matei 2.