Premature optimization is the root of all evils, the 7 principles of fine number optimization

The benefits of code optimization are great, but that doesn't mean all code needs to be optimized, and sometimes excessive optimization is counterproductive-time-consuming, laborious, and thankless.

"The originator of modern computer science" Donald Knuth once said that "premature optimization is the root of all evils" because: it is much easier to make the right program faster than to make the fast program correct.

In project development, there are always programmers who waste valuable time improving code that does not require improvement, rather than adding value through the improvements that have been made. When optimizing a project, where should it be optimized, how should it be optimized, and which should not be optimized? You need to take a look at the 7 things that are mentioned in this article first.

1. What exactly is to be optimized?

At the beginning of the optimization work, you have not yet clearly optimize the content and purpose, then you can easily fall into the wrong. In the beginning, you should have a clear understanding of the effects you want to achieve and other optimization-related issues. These goals need to be clearly stated (at least the technology-savvy project manager can understand and express it), and then you need to stick to those goals throughout the optimization process.

In actual project development, there are often a variety of variables. You may want to optimize this aspect at the outset, and then you may find that you need to optimize the other. In this case, you need to understand these changes clearly and make sure everyone on the team understands that the goals have changed.

2. Choose a correct index of optimization

Choosing the right metrics is an important part of optimization, and you need to follow these metrics to measure the progress of the optimization effort. If the indicators are not chosen properly or are completely wrong, your efforts may be in vain.

Even if the indicators are correct, there must be some discrimination. In some cases, it is a practical strategy to put the most effort into the part of the code that consumes the most time. But keep in mind that most of the Unix/linux kernel time is spent on the empty loops.

It is important to note that if you easily choose an index that is easily achievable, it does not work because it does not really solve the problem. You need to choose a more complex indicator that is closer to your goal.

3. Optimization on the blade

This is the key to effective optimization. Find out where your project is related to your goals (performance, resources, or other) and use your effort and time there.

As a typical example, a Web project is slow, and developers focus most of their effort on database optimization when they optimize, eventually finding that the real problem is slow network connectivity.

Also, don't be distracted by problems that are easy to implement. These issues, though easy to solve, may not be necessary or inconsistent with your goals. Easy optimization doesn't mean you're worth the effort.

4. The higher the optimization level, the better.

In general, the higher the level of optimization, the more effective it will be. According to this standard, the best optimization is to find a more efficient algorithm.

For example, in a software development project, there is an important application with poor performance, so the development team started to optimize, but the performance did not increase too much, then the project staff alternately, the new developers in the inspection code found that the core performance problem is due to the use of bubble sorting algorithm in the table, Lead to the increase of thousands of items.

However, high level of optimization is not "silver bullet". Some basic techniques, such as moving everything to a circular statement, can also produce some optimization effects. In general, a large number of low-level optimizations can produce an effect equivalent to a high level of optimization.

It's also important to note that high level optimizations reduce some blocks of code, so the optimizations you've made for these blocks of code don't make any sense at first, so you should consider high-level optimizations at the beginning.

5. Do not optimize prematurely

Optimizing early in the project can cause your code to be difficult to read or to affect the operation. On the other hand, at the end of the project, you may find that the optimizations you have done have not worked, wasting time and energy.

In the right way, you should take project development and optimization as two separate steps.

6. Dependence analysis, not intuition

You tend to think that you already know where to optimize, which is undesirable, especially in complex software systems where performance analysis data should be first and ultimately intuitive.

An effective strategy for optimization is to sort by the impact of the work on the optimization effect. Find the most influential "roadblocks" before starting work, and then deal with small "roadblocks".

7. Optimization is not a panacea

One of the most important rules of optimization is that you can't optimize everything, and you can't even optimize two problems at once. For example, optimizing the speed may increase resource utilization, optimize storage utilization, and possibly slow down other places. You need to weigh which is more in line with your optimization goals.

Original English: Code optimization as a double-edged sword