No, you normally want that program to execute efficiently enough to do its required job
but... the "required job" is to go as fast as possible - in two ways :
1/ You must go faster than your competitors. Else people will switch, your software will get bad reviews, etc.
2/ you must go fast enough for anything that people will throw at you. And, in many cases, people can throw arbitrarily large problems to your program, and telling them "sorry but it will take 1 hour to process your 2TB dataset" just won't cut it at all. And even when you manage to cut it, then people come at you like "now can this run on a raspberry pi?"
Take for instance image processing software, audio or multimedia software... they will never be fast enough, and there is always an use case where getting a 1% perf improvement will allow a project to make instead of break (especially when working with uncompromising artists).
but... the "required job" is to go as fast as possible - in two ways :
This is sometimes true, but hardly ever. Most software is not image/audio processing software. Most software is not even interacted with directly by humans. Most software exists as a component as part of a larger system, the performance of which is typically determined by a small fraction of that system. In other words, most software is not on the critical path.
Even if you're on the critical path, the performance requirements could be of the form "Here's some data, I need an answer in an hour". If your current system spends 2 minutes computing and delivering the result, why spend time and money making it faster? Just because you're on the critical path for you, doesn't mean you're on the client's critical path.
This is the whole point of performance engineering - identifying which bits are important and then figuring out how to optimise those. Optimising everything to run as fast as possible is a waste of time and effort - worse, it often degrades the overall system by making previously easy-to-understand components more complex and more difficult to reason about. See the whole "Worse is better" thing.
If you're on the critical performance path, go nuts. Throw away the abstractions and take it down to the metal. If you're not? Why bother?
Perhaps the 'I need answer in a hour' is currently acceptable because that's how long people are used to waiting for the answer. If they knew that you could get that answer in 2 minute do you not think they'd ask for that instead?
Like I mentioned previously, Scala's use in Big Data is perplexing. I reckon Cloud providers are making an absolute mint from design / language inefficiencies.
Comments
but... the "required job" is to go as fast as possible - in two ways :
1/ You must go faster than your competitors. Else people will switch, your software will get bad reviews, etc.
2/ you must go fast enough for anything that people will throw at you. And, in many cases, people can throw arbitrarily large problems to your program, and telling them "sorry but it will take 1 hour to process your 2TB dataset" just won't cut it at all. And even when you manage to cut it, then people come at you like "now can this run on a raspberry pi?"
Take for instance image processing software, audio or multimedia software... they will never be fast enough, and there is always an use case where getting a 1% perf improvement will allow a project to make instead of break (especially when working with uncompromising artists).
This is sometimes true, but hardly ever. Most software is not image/audio processing software. Most software is not even interacted with directly by humans. Most software exists as a component as part of a larger system, the performance of which is typically determined by a small fraction of that system. In other words, most software is not on the critical path.
Even if you're on the critical path, the performance requirements could be of the form "Here's some data, I need an answer in an hour". If your current system spends 2 minutes computing and delivering the result, why spend time and money making it faster? Just because you're on the critical path for you, doesn't mean you're on the client's critical path.
This is the whole point of performance engineering - identifying which bits are important and then figuring out how to optimise those. Optimising everything to run as fast as possible is a waste of time and effort - worse, it often degrades the overall system by making previously easy-to-understand components more complex and more difficult to reason about. See the whole "Worse is better" thing.
If you're on the critical performance path, go nuts. Throw away the abstractions and take it down to the metal. If you're not? Why bother?
Perhaps the 'I need answer in a hour' is currently acceptable because that's how long people are used to waiting for the answer. If they knew that you could get that answer in 2 minute do you not think they'd ask for that instead?
Like I mentioned previously, Scala's use in Big Data is perplexing. I reckon Cloud providers are making an absolute mint from design / language inefficiencies.
I have never been in the case where the answer to the question "when" wasn't "as fast as physically possible".