One of the biggest lies in the computer programming arena is Donald Knuth’s quote about “premature optimization is the root of all evil“. He was not wrong if you read his full quote which spans more than a sentence. The problem is, several generations of software developers have been brought up on the abbreviated version of the quote out of context. Do not believe it.
A major factor in deciding not to optimize software programs was Moore’s Law. That law doesn’t actually hold up when it comes to the speed of a computer. When people thought the computer was just going to keep getting faster (like doubling/tripling of speeds), they decided buying a new, bigger, faster computer was cheaper than spending the time to optimize the program. I personally agree with the economic argument in situations where it applies. Still, you can never quite count on today’s data input/output profile remaining constant.
The point of view that you can just throw more hardware at the problem broke down somewhere around 2001 to 2008 depending on how you look at it. Fact is, computers have barely crossed the 5GHz barrier and even if when they do that is definitely nowhere close to the 1THz barrier and beyond. At least in the very near future. The main approach we have today to increasing performance with new computers is simply adding more of them and then running code across multiple cores and multiple computers at the same time.
Cloud computing is the ultimate expression of this. That also partly explains Amazon’s fortunes in cloud (and very closely followed by Microsoft) as many enterprises cannot get similar price/per performance in their own data centers. Scaling a software program through the cloud is an inexpensive way to get performance until the compute hours cross a certain threshold.
What’s left to do?
Write optimized code from the get go. Or, it may not even be code, but something such as database structures and data that code and other processes will rely upon. Simple things like the structure of your file folders. The trade-offs between complex and simple file formats are not clear-cut. Sometimes a complicated file format can lead to a faster program versus a simple file format. One reason sometimes deals with the amount of information you need to retain while processing data. How the data is shaped and where it lives and must go has the biggest impact on performance. Code must be organized accordingly.
Sometimes you are in an enterprise with longer equipment upgrade cycles resulting in tighter hardware constraints by the standards of today’s software frameworks and libraries. Software still has to run fast and it can if you exclude the possibility of scaling it later on newer hardware outside the timetable of your near-term deadlines. Perhaps you are deploying to mobile and need the best performance you can get in a tightly constrained space. While mobile processors are generally said to be several times faster than supercomputers of the 1970s and 1980s, they are still not as fast as today’s desktop/laptop processors. You still need good performance in what is, by today’s standards, a constrained processing envelope. Even laptop battery life can be influenced by efficient software code. As it turns out, just like security, you cannot easily retrofit solid code execution performance after the fact. You have to start with performance as a goal or have the skills to write high performance software.
I found several good starting points for this: