August 23, 2011 at 10:04Belated Optimization
- Transfer
Your attention is invited to a translation of Dennis Forbes's article " The Sad Reality of Post-Mature Optimization ". Excellent illustrations are also taken from the original article.
The famous statement “premature optimization is the root of all evils” belongs to the pen of Donald Knuth. Unfortunately, the original meaning of this phrase has long been lost, and recently it has been used only as an excuse, allowing you to beat off any claims to the speed of the program.
At what stage in development is it time to pay attention to performance? At what point does optimization cease to be premature and become timely?
The common opinion is this: only care about performance when you have already written most of the code. It would seem that everything is very simple: we start the profiler, find all the problem areas in the code and optimize them. With this approach, the result (it seems!) Should be the same as if you were thinking about performance from the very beginning. Familiar words, right?
Having worked in the industry for more than one year and completing more than a dozen projects, I can say with confidence: this is complete nonsense. In fact, everything happens in a completely different way.
This is what the profiler should show if you run it on an ideal, hypothetical program that was written from the very beginning taking into account high performance requirements. All methods in it are executed equally quickly, and there are simply no places where performance would be squandered.
When you set the profiler on a project written under the slogan “say no to premature optimization!” , You expect to see something like that.
In practice, this will never happen. No, yes . If you did not put productivity at the forefront from the very beginning, then inefficient solutions will appear everywhere, infecting every square kilobyte of code in your project. Why use hash tables when you can iterate through a huge array stupidly? Why write SQL queries when you can use LINQ for everyone, constantly filtering out a huge amount of redundant data?
In most cases, the profiler will draw you this:
This situation is absolutely typical. If you have not thought about performance from the first days of the project - believe me, you will not remember about it until the very end. You don’t have to comfort yourself with hopes like “we will find the most inefficient function, optimize it quickly, and everything will work faster immediately!”. With this approach, all functions will be infected, and targeted treatment will not help you. Moore’s law will not come to your aid either: the performance of a single processor core has not changed for several years. Nine women can never give birth in one month; so in your case, dreams that sooner or later good hardware will allow your program to work quickly, they will break into physical limitations.
Want some examples from life? You are welcome. Minimum rendering time for one page of a business portalSugarCRM - in the region of 100 milliseconds, even on the best hardware. In the world of web applications, this state of affairs does not bother anyone (everyone has long been accustomed to the fact that every click on a web page is processed for several seconds), but the situation has reached the point that the short response time has become serious for some web services competitive advantage. I really like the Rdio Internet radio , but if I find an analogue of it that will not get me a second delay between page switching, then I will immediately switch to it.
You rarely manage to fix all bugs before release; in the same way, you will not be able to solve all performance problems in a short time. The situation is very similar to trying to parallelize an algorithm that was not originally intended for this: in principle, it is possible, but most likely you will need to rewrite everything from scratch.
To summarize the above: the useful principle expressed by Knut was brought to the point of absurdity. When someone talks about premature optimization, he almost certainly does not mean at all what Knuth had in mind.
The famous statement “premature optimization is the root of all evils” belongs to the pen of Donald Knuth. Unfortunately, the original meaning of this phrase has long been lost, and recently it has been used only as an excuse, allowing you to beat off any claims to the speed of the program.
At what stage in development is it time to pay attention to performance? At what point does optimization cease to be premature and become timely?
The common opinion is this: only care about performance when you have already written most of the code. It would seem that everything is very simple: we start the profiler, find all the problem areas in the code and optimize them. With this approach, the result (it seems!) Should be the same as if you were thinking about performance from the very beginning. Familiar words, right?
Having worked in the industry for more than one year and completing more than a dozen projects, I can say with confidence: this is complete nonsense. In fact, everything happens in a completely different way.
This is what the profiler should show if you run it on an ideal, hypothetical program that was written from the very beginning taking into account high performance requirements. All methods in it are executed equally quickly, and there are simply no places where performance would be squandered.
When you set the profiler on a project written under the slogan “say no to premature optimization!” , You expect to see something like that.
In practice, this will never happen. No, yes . If you did not put productivity at the forefront from the very beginning, then inefficient solutions will appear everywhere, infecting every square kilobyte of code in your project. Why use hash tables when you can iterate through a huge array stupidly? Why write SQL queries when you can use LINQ for everyone, constantly filtering out a huge amount of redundant data?
In most cases, the profiler will draw you this:
This situation is absolutely typical. If you have not thought about performance from the first days of the project - believe me, you will not remember about it until the very end. You don’t have to comfort yourself with hopes like “we will find the most inefficient function, optimize it quickly, and everything will work faster immediately!”. With this approach, all functions will be infected, and targeted treatment will not help you. Moore’s law will not come to your aid either: the performance of a single processor core has not changed for several years. Nine women can never give birth in one month; so in your case, dreams that sooner or later good hardware will allow your program to work quickly, they will break into physical limitations.
Want some examples from life? You are welcome. Minimum rendering time for one page of a business portalSugarCRM - in the region of 100 milliseconds, even on the best hardware. In the world of web applications, this state of affairs does not bother anyone (everyone has long been accustomed to the fact that every click on a web page is processed for several seconds), but the situation has reached the point that the short response time has become serious for some web services competitive advantage. I really like the Rdio Internet radio , but if I find an analogue of it that will not get me a second delay between page switching, then I will immediately switch to it.
You rarely manage to fix all bugs before release; in the same way, you will not be able to solve all performance problems in a short time. The situation is very similar to trying to parallelize an algorithm that was not originally intended for this: in principle, it is possible, but most likely you will need to rewrite everything from scratch.
To summarize the above: the useful principle expressed by Knut was brought to the point of absurdity. When someone talks about premature optimization, he almost certainly does not mean at all what Knuth had in mind.