Reminds me of the time some dev[0] accidentally recreated the traveling salesman problem, created unit test with 5 items in it, said "looks good", and pushed it.
[0] - me
If you ignore linear/non-comparison algorithms like radix or bucketsort. Those are much harder to optimize to your particular problem but should result in significantly lower run times when properly adapted.
Re:Go will use pdqsort in next release
by robertlagrant on Thursday April 21, 2022 @06:16AM
(#31107684)
Sadly I can't disagree for myself either! Doing diligent performance testing is hard to prioritise.
But when it fails, well, it will fail big... In my experience, some devs (me included :-)) make tests with a reduced dataset 'cos they can iterate faster and then go in production without testing on a real-size dataset. All of a sudden, the o(n²) edge case becomes, well, a problem :-)