Premature optimization ? Did you see your code?

Throughout my audits, conferences and tool installations, one of the first arguments against eco-design (and overall against the need to optimize the code) is a magic phrase: “premature optimization is the root of all evil.” Two words “premature” and “evil” that reinforce the idea that thinking about code optimization would be a mistake.

It is necessary to return to the origin of this sentence before taking it as an acquired or a law of programming. Donald Knuth wrote in 1974:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed” … Maybe in 1974 but not so much in the years 2010! We have many constraints taken into account in devs (functionality, scalability, security …) but not necessarily performance. The weapons race announced with horizontal scalability, vertical, PAAS, cloud … made us even more forget the need to optimize. The message induced by Moore’s law thrusts the nail. If we do not understand that it is not necessary, or counterproductive to optimize, is that we missed a lot of things. So no, in 2016, developers do not spend more time thinking about optimization.

Far be it from me to say that one does not optimize the software, one optimizes rather in “mode fireman”. Critical client rollback, application unusability … Performance is not seen as an evaluation criterion, but rather as non-performance as a bug. And that’s the problem. Rather than training armies of developers in the culture of performance, experts are trained to analyze performance problems. Results : performance analyzes only in times of crisis, profilling software complex and uncommon, and therefore costly.

I blacken the trait, yes because the devil is not in premature optimization and it is in our current image of performance. When performance is integrated as a development requirement, it is not necessarily the most ideal. Indeed, performance is a quality of use of the software: display time, transaction in base … If we take the ISO 25000 standard on quality, we speak about efficiency rather than performance:

And when one looks at what hides efficiency: Temporal behavior and use of resources.

resources expended in relation to the accuracy and completeness with which users achieve goals

We see it in the web world: web performance focuses on displaying the page in less than x seconds. Top ! What about the other characteristic of resource consumption? We forget the overall efficiency to focus on an important but not unique characteristic. How many servers are used to display a page? Number of requests? Energy consumption ? And when you take into account the number of queries, it is only to respect the display performance. Why ? Because a too long view of a page is seen by the user as a bug, and that’s normal. But from the point of view of the developer, the display time should be seen as one of the usage characteristics among others in all those covering the efficiency of the software.

And this observation could be applied to many axes of software optimization. The “bottlenecks” of the software were naturally managed: we optimized the costly requests, we minimized the times of launch of the applications, we will reduce the times of display of the pages … but We will have worked on the overall efficiency of the software? No. We carried out a study with the ADEME called Web Energy Archive and proved that there was no correlation between web performance and efficiency (and in particular energy efficiency). Here is the distribution of the measure on 500 sites:

We arrive at a software “uniformly slow”. No sense of non-performance annoying to the user because it accepts the current performance (it does not even believe in an immediate launch time applications), so why go further? Then the software becomes a bit slower:

that software is getting slower more rapidly than hardware becomes faster. — https://en.wikipedia.org/wiki/Wirth's_law

We always find arguments for not optimizing:

• Optimization premature: Ouh la, it should not have an impact on performance. All the more so because it would require us to measure performance, something that we do not do … even less for efficiency.
• Moore’s Law: why optimize while in 18 months, we will have platforms even more powerful?
• The price of the equipment is always lower. Indeed, the prices of servers, VM, memory have decreased. OK but what is the real cost of a website knowing that in 2 seconds, 40 servers are contacted? On how many VMs are hosted servers (we intuit that with scalability, micro-services …, the figure increases steadily)?
• There is more to save elsewhere: optimization is good but it is for others. For the dev, it is the infra where there is more fat; For the infra, it is the constructors …

These brakes are partially understandable: we have been conditioned for more than 20 years on the race to the power of hardware and the immateriality of the software. We are talking about technical debt in development teams, I think technical debt is even greater. The non-optimization of efficiency created an important debt of efficiency. And the effort can be important to solve it: training of developers, tools to set up … It is simpler to push the problem under the mat or in others. One sees it in the GAFA: we speak for several years of Green IT in the data centers (free cooling, recovery of heat …) but what real actions on the consolidation and the efficiency of the software? The actions exist but are still timid. One even sees promoters of the Green IT pass messages according to which eco-design of the software would be a technical and minor axis. I would say major and complex if we were to treat it seriously.

Virtual, Digital, Digital, Cloud … Applications are not seen as concrete objects, like products … Yes the code has a strong adherence to the hardware, yes a code without hardware will not provide a service. It is simpler for everyone to encompass the problematic in a somewhat blurry that is IT or Digital. However, divide each component, each product can work seriously on each element. I am not saying that a systemic approach is not necessary, just that the issue is complex (debt of efficiency). In addition, the software is a product. Some will try to deny it arguing that there is no software without hardware. Yes an engine can be considered a product, and it does not make sense without chassis and wheel, but it is a product. And we are working on its efficiency. This product classification is also necessary in other areas such as quality. Many countries consider software legally as a product (a somewhat old but always current article)

Moreover, a bias in our profession does not help to improve this. As a developer, we always aim to improve our productivity. It is normal, the constraints becoming stronger: security, faster development cycle, evolution of technologies to take into account … We therefore make choices according to this. To return to ISO 25000, we prefer more the internal quality of the product that touches us than the quality of use. Internal quality as defined by ISO:

Maintainability, maintainability, yes but it is only one of the 8 characteristics of internal quality (Portability, Reliability, Compatibility …). Yes it is important but it is necessary to balance our choices and efforts on all the characteristics of our software. The convenience of developers should not be prioritized in relation to the needs of users. It may seem like a constraint, but I have confidence in our efficiency.

So no, greatly optimize the code is not the cause of all the evils, quite the contrary, it is a solution. No, there is not only 3% critical code, but rather 97% critical code: Heavy frameworks, increasingly used libraries and ultra-used web services. All the experiments I see show: a small effort on any part of the code leads to drastic decreases in resource consumption. The situation in 1974, which was close to the material and where the code was uniformly efficient and efficient, is a long way off. We are now faced with a uniformly slow and inefficient code accelerated by more and more material (s). More heart to run a spreadsheet, more battery capacity to run our mobile applications, more data centers to meet the Iot. This would not be a problem if resource cost and environmental impact did not exist. But this is not the case. It is urgent to forget the obsolete litemotivs of the software industry and not to fall into the “silver bullet” of the cloud (at least on the axis “no need to optimize”). And go beyond simply optimizing performance. And you call it what you want: efficiency, optimization of performance and resources, eco-design software …