Arjun Reddy

Ranch Hand

Posts: 629

arulk pillai

Author

Ranch Hand

Ranch Hand

Posts: 3404

posted 8 years ago

There's no one "fastest" algorithm; there are some special-case sorts you can do in time proportional to the number of items, but most general-purpose fast sorts perform in time proportional to the number of items times the logarithm of that number. Sometimes a fast sort can "accidentally" run much more slowly, if, for example, the data is already mostly sorted. High-quality implementations can avoid this kind of problem, which is why it's always a much better idea to use a library sort than to try to implement your own.

Colletions.sort() is an implementation of mergesort, by the way.

Colletions.sort() is an implementation of mergesort, by the way.

posted 8 years ago

"fastest sorting" has been an academic research topic for 50+ years. As posted above, there is no "fastest" in all cases. Read any book on algorithm analysis, they all have a chapter or two on the topic.

Be careful if you get into large sets to sort. Some generally well behaved algorithms fail badly in some cases. Some do really bad if the set is already sorted, some if the set is already reverse sorted, etc.

Know your data before you pick one.

if your data is essentially randomly ordered, then the Collections.sort() is fine.

Be careful if you get into large sets to sort. Some generally well behaved algorithms fail badly in some cases. Some do really bad if the set is already sorted, some if the set is already reverse sorted, etc.

Know your data before you pick one.

if your data is essentially randomly ordered, then the Collections.sort() is fine.