Re:Sorting Algorithm Cheat Sheet
by saagarjha on Friday April 26, 2019 @04:23PM
(#19761413)
Sorting is such a foundational problem in computer science that pretty much every job will end up relying on the runtime of sorting algorithms. Not every job requires being able to write a bulletproof dual-partition QuickSort, of course, but knowing complexity bounds is important, even if you’re just calling your standard library’s implementation: it places fundamental bounds on what things you can improve.
[ Parent
| on HN ]
Dev with decades of experience here - I've worked with a variety of languages and platforms, and across different domains. I'm not sure I've ever had to implement a sorting algorithm, or even had sorting as an optimisation issue (and I love micro-optimisation, a bit too much TBH!). I've had to sort things, of course, but standard (or at least "common") libraries invariably have sorting functions built-in.
Pretty much every job? I'd say about 10%. With all the web and web-adjacent jobs around, maybe even less. Most stdlibs are already written in a sensible way, so calling "sort" usually means calling quicksort. Most people just do not care, they have tickets and bosses to worry about.
Absolutely. While every job will depend on sort, so many of them will have negligible benefit by changing the least efficient algorithm to the most.
And most of them just use a native language sort that does something relatively smart out of the box.
It's good to write all of these at don't point so you understand why things are inefficient.