I've done some comparison between different sort algorithms, and almost nothing beats the build int Arrays.sort, which is a quicksort. And that algorithm is built to well handle nearly sorted sets of data too, which otherwise normally is a problem for quicksort. I would guess that might be a problem in your case.
A major problem in java is the memory allocation and garbagecollection, and quicksort is in-memory, which is a major reason to use quicksort. Mergesort is not in memory, but it can be programmed smartly to not allocate that much extra memory. I would recomend quicksort though, especially the built in one in Arrays.sort.
If you plan to do it yourself, quicksort is not good for nearly sorted arrays/sets.
If you have a sorted set of items that changes order only slightly for each iteration, which might be the case for moving 3d polygons, a smarter algorithm can be used, some sort of bubble sort, where you only switch wrongly placed items (iteration for the moves could be done in logarithmic fashion). This will also be in memory.
Gil
> I've done some comparison between different sort
> algorithms, and almost nothing beats the build int
> Arrays.sort, which is a quicksort. And that algorithm
> is built to well handle nearly sorted sets of data
> too, which otherwise normally is a problem for
> quicksort.
> If you plan to do it yourself, quicksort is not good
> for nearly sorted arrays/sets.
Unless you do it yourself in a smarter way. Using the
first item as the pivot isn't smart and can cause the
sections of the list to be badly unbalanced. Using an
item in the middle is almost always good, (you would
have to carefully contrive the data to get the worst
case time) but you can do better by taking the median
of the first, last and middle as the pivot. I guess
that's what Arrays.sort does. A random item splits
the array into 33-67 on average. The above makes it
nearer to 50-50 (maybe 45-55).