And when you compare costs, the difference is likely to be even more significant because developer time generally costs a lot more than machine time.That's a red herring. Machine time is utterly unimportant. But what is important is the end user. Would you accept it that the movie you're watching on your PC freezes because developer time costs more than machine time? In general, it's very hard to say anything about developer time vs. running time. Many programs aren't designed to be run once, they will be run thousands, or millions of times.
In this specific case, lifting the descending/ascending switch outside of the sort (be it by using reverse, or two comparison functions) doesn't cost anything. It's the same amount of code, making the same decisions. I've a hard time imagining a coder that would take hours more time to do the same amount of things.
A good coder will always program with efficiency in mind - doing thinks like this (lifting code that will yield the same result out of a loop) should be automatic. And don't come with the mantra premature optimization is the root of all evil, because we're not sacrificing anything. The code doesn't become less flexible, harder to read or harder to maintain. It doesn't trade memory or some other resource for speed either.
In reply to Re^3: sort direction
by Perl Mouse
in thread sort direction
by rsiedl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |