Late optimization
Your attention is invited to the translation of the article " The Sad Reality of Post-Mature Optimization " by Dennis Forbes. Excellent illustrations are also taken from the original article.
The famous statement “premature optimization is the root of all evil” is written by Donald Knuth. Unfortunately, the original meaning of this phrase has long been lost, and recently it has been used only as an excuse, allowing it to fight off any complaints about the speed of the program.
At what stage of development is it time to pay attention to performance? At what point does optimization stop being premature and timely?
')
A common opinion is: take care of performance only when you have already written most of the code. It would seem that everything is very simple: run the profiler, find all the problem areas in the code and optimize them. With this approach, the result (seemingly!) 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 having completed more than a dozen projects, I can confidently say: this is complete nonsense. In fact, everything happens quite differently.
This is what the profiler should show if it is run on an ideal, hypothetical program, which was written from the very beginning with regard to high performance requirements. All methods in it are executed equally quickly, and there is simply no place where the performance would sink.
When you set up a profiler on a project written under the slogan “let's say no” to premature optimization! ” , You expect to see something like this.
In practice, this will never happen. No way . If you did not put performance 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 clearly iterate over a huge array? 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 it until the very end. No need to indulge in the hopes of the type “we will find the most inefficient function, quickly optimize it, and everything will work faster at once!”. With this approach, all functions will be infected, and the cure will not help you. Moore's law will not come to your rescue either: the performance of an individual processor core has not changed for several years now. Nine women can never have a baby in one month; so in your case, the dream that sooner or later a good iron will allow your program to work quickly will break about physical limitations.
Want examples from life? You are welcome. The minimum rendering time for one page of the SugarCRM business portal is around 100 milliseconds, even on the best hardware. In the world of web applications, this state of affairs is not particularly embarrassing (everyone has long been accustomed to the fact that every click on a web page is processed for a few 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 Rdio Internet radio, but if I find an analogue of it, which will not get me a second delay between switching pages, I will immediately switch to it.
You rarely fix all the 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 the attempt to parallelize an algorithm that was not originally intended for this: in principle, this is possible, but you will most likely need to rewrite everything from scratch.
To summarize the above: the useful principle expressed by Knut was brought to a complete absurdity. When someone talks about premature optimization, he almost certainly means not at all what Whip had in mind.
The famous statement “premature optimization is the root of all evil” is written by Donald Knuth. Unfortunately, the original meaning of this phrase has long been lost, and recently it has been used only as an excuse, allowing it to fight off any complaints about the speed of the program.
At what stage of development is it time to pay attention to performance? At what point does optimization stop being premature and timely?
')
A common opinion is: take care of performance only when you have already written most of the code. It would seem that everything is very simple: run the profiler, find all the problem areas in the code and optimize them. With this approach, the result (seemingly!) 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 having completed more than a dozen projects, I can confidently say: this is complete nonsense. In fact, everything happens quite differently.
This is what the profiler should show if it is run on an ideal, hypothetical program, which was written from the very beginning with regard to high performance requirements. All methods in it are executed equally quickly, and there is simply no place where the performance would sink.
When you set up a profiler on a project written under the slogan “let's say no” to premature optimization! ” , You expect to see something like this.
In practice, this will never happen. No way . If you did not put performance 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 clearly iterate over a huge array? 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 it until the very end. No need to indulge in the hopes of the type “we will find the most inefficient function, quickly optimize it, and everything will work faster at once!”. With this approach, all functions will be infected, and the cure will not help you. Moore's law will not come to your rescue either: the performance of an individual processor core has not changed for several years now. Nine women can never have a baby in one month; so in your case, the dream that sooner or later a good iron will allow your program to work quickly will break about physical limitations.
Want examples from life? You are welcome. The minimum rendering time for one page of the SugarCRM business portal is around 100 milliseconds, even on the best hardware. In the world of web applications, this state of affairs is not particularly embarrassing (everyone has long been accustomed to the fact that every click on a web page is processed for a few 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 Rdio Internet radio, but if I find an analogue of it, which will not get me a second delay between switching pages, I will immediately switch to it.
You rarely fix all the 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 the attempt to parallelize an algorithm that was not originally intended for this: in principle, this is possible, but you will most likely need to rewrite everything from scratch.
To summarize the above: the useful principle expressed by Knut was brought to a complete absurdity. When someone talks about premature optimization, he almost certainly means not at all what Whip had in mind.
Source: https://habr.com/ru/post/126818/
All Articles