Code optimization is actually a double-edged sword!

Why is optimization not always a good idea?

Optimization is the process of improving a unit that has already started work. For end users or customers, this is as attractive as a cherry. For the same reason, code optimization is very popular in the software industry. But is it really always beneficial to optimize code? I have been working in the software industry for more than five years, and what I can tell you is that code optimization is a double-edged sword. If not handled properly, it may do more harm than good.

In software terminology, we use the term "premature optimization" to mean bad or unnecessary optimization. Easier said than done, in fact, it is not easy to find premature optimization. In this article, I will share with you some methods that can help you optimize and avoid premature code optimization.

let's start.

10,000 root of evil

Code optimization is the process of modifying a software system in order to make the program execute faster, or to enable it to use less memory or other resources at runtime. Most developers believe that code optimization is a necessary step in the software development process. But in fact it is not the case. Never try to optimize the code of an application prematurely—or only try to optimize the code when needed.

Premature optimization is the root of all (or at least most) evil in programming. --Donald Knuth

The source code written based on concise ideas is sufficient to meet the performance requirements in 99% of the cases. And this will greatly improve the maintainability of the application.

example:

  • Use pointer arithmetic instead of array symbols in C language, including the use of codes such as the following styles:

for (p = q; p < lim; p++)
  • Rebind global variables to local variables in Lua, for example:

local table, io, string, math= table, io, string, math

In short, if a technique makes the program more difficult to understand, then it is premature optimization.

The biggest problem with premature optimization is that it may introduce unexpected bugs and may waste a lot of resources and time.

"There is no doubt that the holy grail of efficiency has led to abuse. Programmers waste a lot of time thinking about or worrying about the speed of non-critical parts of their programs, and these attempts to improve efficiency will actually have a strong negative impact on debugging and maintenance. We should forget those small efficiency improvements. For example, in 97% of cases, premature optimization is the root of all evil.

However, we should not miss this critical 3% optimization. A good programmer will not be complacent because of the above reasoning, he will carefully review the key code wisely, but it must be after the key code is identified. "

— Structured Programming with go to Statements (1974)

2 why developers tend to optimize prematurely

People often unknowingly pursue premature optimization. This may have a variety of reasons, including:

  • They can easily spend a lot of time thinking about unimportant things in order to get a false sense of progress.

  • They just don't know how to plan ahead and figure out what tasks they should do at each stage of the development process.

  • They will even plan their future course of action before they even start trying, because it is always easier to talk on paper.

  • This represents a phenomenon in which people spend disproportionate amounts of resources to deal with relatively minor problems.

3 how to avoid premature optimization

When determining whether something should be optimized, you should consider some factors and ask yourself a few important questions.

The following questions can help you decide whether it is worth it:

  • Why should we optimize?

Is it really necessary to optimize at this stage, or are you just focusing on it because you want to avoid dealing with other issues?

  • What are the benefits of optimization?

You should have a good reason to optimize it, because it will require resources. It should be enough to be worth everyone's time and have a major impact on the project.

  • How high is the cost of optimization?

How much team effort and time are needed to achieve optimization? Will this affect the ongoing workflow of the project? Such things need to be evaluated before execution.

  • What are the consequences of optimization?

What problems will this optimization bring to you in the near future? Will it increase the testing scope of the application?

After answering all these important questions and discussing them in the team, you can decide whether you need to optimize.

4 final thoughts

Any coding practice that makes your code difficult to understand in the name of performance is not worth it. You should not optimize when there is no measurable performance problem, because this is premature optimization, even if you think you will get a performance improvement, don't do it.

Like all other performance issues, you should evaluate it before starting any optimization.

Original link:

https://codeburst.io/code-optimization-is-like-a-double-edged-sword-86ba957386cf

1. It is said that many software engineers envy hardware engineers

2. Several communication interfaces commonly used in microcontrollers, such as I2C, SPI, UART, etc.

3. The results of the January rankings of programming languages ​​are released, and we have five important findings

4.5 yuan changed to 70, hey, the chip is out of stock again

5. How does the RISC-V processor design the instruction set? What's so special

6. Macro definitions commonly used by embedded engineers

Disclaimer: This article is reproduced online, and the copyright belongs to the original author. If you are involved in the copyright of the work, please contact us, we will confirm the copyright based on the copyright certification materials you provide and pay the author's remuneration or delete the content.

Guess you like

Origin blog.csdn.net/DP29syM41zyGndVF/article/details/114311770