To what extent is premature optimization a problem?

Question

Premature optimization is when there is an excessive concern on the part of the programmer with the performance of the application.

It is usually condemned by some programmers for reasons such as:

• This can make the code more complex
• Your productivity drops, you waste time
• There is a great chance that you will worry a lot about optimizations that will not bring about a noticeable improvement by the user

The recommendation would be that you first make it work, and then identify the performance bottlenecks and correct them.

However, there are certain optimizations that must be taken into account from the beginning, as later can become more difficult to optimize.

The extent to which we should care about performance, without causing a considerable loss in productivity?

Answer 1

An analogy

When a teacher requires his students to do a certain task, what is one of the most important questions to be asked?

"What is the delivery time?"

The delivery can be immediate, for the next day or until the end of the semester, it is not?

We can use this analogy to understand what level of optimization we should apply in a certain functionality or even in a whole software.

The non-functional requirements of a system shall specify the performance expectations of critical functionalities.

For example:

The system must support simultaneous access of up to 1000 users.

Or else:

Response time should not exceed 5 seconds for up to 10 thousand users.

Based on these characteristics (which are the subject of another study), adding our experience and perhaps a prototype, we can then decide how much to invest in optimization from an early age, although in this case I would not exactly call premature.

The problems

Micro optimizations are a mistake

The main problem with optimizations that are premature is when the developer assumes he’s making code faster, when in fact he doesn’t even have evidence that it’s actually going to happen in the "finally".

Much has been discussed here at Sopt about micro benchmarks and small differences between commands, just to cite an example. In the link quoted, it is stated that multiplication is faster than division in Javascript. If one takes this for truth always, one will end up realizing that, in fact, in some browsers the opposite may be true, depending on some circumstances.

And we haven’t even started talking about performers, Jits, cache and other dynamic optimization mechanisms that interfere with all of this.

Therefore, virtually every micro-optimization is doomed to failure, sooner or later, since something can be done automatic, then this may be automated in the next version of the compiler or interpreter.

On the other hand, still in the Javascript line, there are projects that demand high performance. An example is the tracking js., that implements real-time computer vision, where each processing cycle counts.

In cases like this, these micro optimizations are welcome, but this is hardly achieved already in a first development, on the contrary, practical tests will show which optimizations actually positively affect performance.

Requirements change

Also, as we all know, requirements are extremely changeable as far as the opinion of the end user of the system.

So another big problem is that premature optimizations throw away the time invested and, consequently, the money.

Real effect

Another point is that many premature optimizations are virtually useless. For example, using a field byte instead of int in the database may seem an interesting "optimization" during the beginning of the modeling, but ultimately, if the system makes a select * the gain will be practically nil.

If we apply the Pareto Principle here, we would say that 80% of performance problems should be at most 20% of the code. This means that, most likely, we could achieve proper performance for a common system by focusing only on priority features. And then we get to a point where the effort to improve becomes so great that it’s just not worth it.

Completion

We must avoid labels.

Optimization is always welcome when we know what we’re doing and we have a reason for it.

I could say that a premature optimization is a thoughtless optimization or even a unnecessary optimization, that brings more loss than I earn.

So, finally answering the general main question, an optimization turns out to be bad when it gets in the way more than it helps.

Answer 2

First let’s understand where the term "premature optimization came from:

Premature Optimization is the root of all evil -- Donald Knuth

You can see the quote on Wikiquote (and see that the source is actually Tony Hoare).

I will say that half quotation is the root of all evil :P

We should Forget about small efficiencies, Say about 97% of the time: Premature Optimization is the root of all evil

See the Wikipedia article on optimization.

Premature optimization means only that you should not pursue small gains and mostly uncertain gains. And uncertain gains are the most there are. People assume some behavior and program on top of this assumption. What you’re optimizing is possibly creating a bottleneck in another place where optimization would be more useful.

According to the quote, 3% of the time you should optimize (even for small gains). Okay, this number can be half-guessed, but let’s face it, it’s not a negligible number. If optimization is needed, it should be done. And made by who knows how to achieve the desired result. You can spend time optimizing code, can leave complex code to get performance gains, provided they are absolutely necessary.

The concern with exaggeration in the optimization attempt is more with the ineffectiveness of the action than with the productivity, although this may be a legitimate concern as well. Is related a little not to make the code complex and "dirty" unnecessarily, but because this can turn against the goal.

The bad part of this quote is that it turned into "never optimize" and we see software without any worry about performance.

The mistakes made

• Correct design is useful and important

  Many programmers don’t care about learning to even identify algorithm complexity and understand the Big O Notation (table of complexities) and create exponential routines by accident or abuse linear algorithms when a logarithm or constant is easily obtained. Or they still don’t understand that constant O(1) doesn’t always mean faster. Often the programmer even knows a little about the subject but makes assumptions that prove false in practice. One of the dangers of understanding much of this subject (of course the solution is not to ignore them) is to fall in love with the theory. And this is when the premature optimization will take place. I talk more about this subject in that reply.

  It is important to understand the problem and give real optimization solutions where it is needed as soon as possible when you know based on realistic data that it will be needed. Only qualified experience allows you to do this competently. Even though it’s a difficult thing, even the best programmers will have trouble identifying the bottlenecks early. So the strategy is not to cling to optimization as if it’s the most important thing to do. Understand that at a certain moment it is better to leave it for later and leave possibilities that allow and facilitate it. It is necessary to avoid a design make it harder to optimize later. But keep in mind that solving performance problems later is harder than solving before.

  Another common mistake that remains design is in the choice of language or technology adopted. Most of the time this does not matter for the performance but there are cases that the correct choice is fundamental. Finding that doing in Assembly ensures the best result is as silly as thinking that everything can be done in Ruby with impunity.

  The design involves the strategic and tactical part of the application. It involves the architecture, choice of technologies, data structures and algorithms used.

• We are no longer evolving in processor computational power as before. We can no longer count that evolution will fix certain performance problems.

• Spending user time usually costs more than the additional expense to make good optimizations. Having a product with poor performance is more expensive than developing optimization. Performance is Feature and not bug. It seems obvious but many programmers have learned that optimizing is creating wrong code, bugle.

• Micro-optimization is bad.

  In the other answers it is quite obvious where you should not optimize: do not do micro-optimizations. Often this is used as an excuse not to optimize where it should. They can be made if they are necessary, obtain measured gains and do not harm the code.

  This does not mean opting for any form. If you have two "clean" ways to do it, there are no drawbacks, and one of them is actually faster than the other, there is no reason to opt for the slower one.

  One of the mistakes I see in these evaluations is that the programmer doesn’t care about a small gain on a harmless method, and in general it’s not to worry too much at all, but he forgets that this method will be used in an algorithm with an exponential problem that will run trillions of times. Well evaluated the micro and forgot the macro. In this case the macro solution goes through the micro solution. Small optimizations are very useful when you know where and why.

  Most often a micro-optimization should come after the correct verification and evaluation that it is needed. This is the operational part of development.

  Reinventing the wheel is often micro-optimization. Except when it’s not :)

Completion

Worrying about optimization is something good, even the anticipated optimization. Worrying too much, obsessing, not knowing where to optimize, where to invest your time, not knowing how to prioritize, not understanding the problem, not having commitment is something bad.

Programmers lack knowledge to avoid that optimizations come by accident, as well as a theoretical optimization turns to harm.

Expected optimization is different from premature optimization. If everyone understands an optimized construction (with real results) this cannot be considered premature optimization. There is a lot of preciousness in these speeches for clean code (do not misunderstand, clean code is a good thing, I do this before there are books on the subject).

Sources:

• THE FALLACY OF PREMATURE OPTIMIZATION (is really a very good text that I agree 100%)
• The ːPremature Optimization is evil' Myth

Answer 3

There is a principle called YAGNI - You Ain’t Gonna Need It ( You Won’t Need It ) It comes to this.

We have to worry about performance and resources at all times, about good practice. But the level of optimization that will be done will depend a lot on the purpose of the code.

Assuming you are creating an API for external access and have a method that will be called on average 1 time per day per client, such as a Checarporatualizations. And also another that is called several times, as an authentication.

The method of checking for updates does not need much effort, since the authentication, it would not be good to take long.

Still, anticipating performance of something expected that you will need is valid, imagine that if any customer, in a certain day, decides to check for updates every 100ms can slow down the system, hence I believe that.