▲ | dvh 3 days ago | ||||||||||||||||||||||
Isn't this just another case of premature optimization? Shouldn't you be adjusting sorting algorithms only when customer complains? | |||||||||||||||||||||||
▲ | grues-dinner 3 days ago | parent | next [-] | ||||||||||||||||||||||
I think the article basically had this conclusion. Think twice before optimising here because you may be able to squeeze something out for a very limited scenario but it can have ugly failure modes and it end up being slower in some cases. Plus it takes time and effort. And modern standard sorts are "unreasonably" fast anyway for many practical purposes. Then again only thinking of fixing things when a customer complains is a way to end up with a leaning tower of hacks which eventually ossify and also the customer (or rather the users, who may not be the customer especially in business software) may be putting up with dozens of niggles and annoyances before they bother to actually report one bug because they can't work around it. | |||||||||||||||||||||||
▲ | hyperpape 3 days ago | parent | prev | next [-] | ||||||||||||||||||||||
It only makes sense to talk about premature optimization in the context of building a production system (or a standard library). This is research or experimentation, designed to improve our understanding of the behavior of algorithms. Calling it premature optimization makes no sense. | |||||||||||||||||||||||
▲ | codegladiator 3 days ago | parent | prev [-] | ||||||||||||||||||||||
This is pushing the limits to identify the boundaries | |||||||||||||||||||||||
|