/ * This article is an translator's Gotw (GURU of the Week) series of self-entertainment translations, the original copyright is the author of Hub Sutter (the famous C expert, "Exceptional C " author). The translation of this article did not have the consent of the original author, only for learning discussion. - Translator: Yang Weiyuan, Huang Sen Tang * /
# 33 Inline.
Difficult: 4/10
Contrary to the usual view, inline is not a word with magic. However, when you use it properly, it is a useful tool. The question is, when should we use it?
problem:
1. Is it efficient to use the intra end function?
What should you do when you decide when using the inline function?
Solution:
1. Is it efficient to use the intra end function?
Not necessarily increased.
First of all, if you answer this question directly and don't ask you: "I want to optimize what", you will fall into a classic circle. The first thing should be asked: "What is your efficiency refers to?" The above problem refers to the size of the program? Memory occupancy size? Running speed? Development speed? Compiling speed? Or what other?
Second, in contrast to the usual opinions, the inline will increase or reduce efficiency:
a) The size of the program. Many programmers believe that the inline will increase the size of the program, since only one function code is replaced, the compiler creates a copy in each place where the function is used. This is usually correct, but it is not always correct: If the size of the function is smaller than the code that the compiler must generate, the internal link will reduce the size of the program.
b) Memory occupation Size: In addition to the size of the program (above mentioned above), inline usually uses only small or no effect on the memory of the program.
c) Running speed: Many programmers believe that the inline function increases the time of operation, as it eliminates the call to the function, and because of the mask function call to compile the most optimized opportunity. This can be said to be correct, but many times: If the function is not frequently called, this usually has no significant increase in the running speed of the entire program. In fact, the opposite situation happens: If the inline increases the size of the call function, it reduces the call time, which means that if the cycle is not placed in the processor's cache, the speed of the entire program In fact become worse.
c) execution time. Many programmers speculate that the inline function improves the execution speed, because avoiding the overhead of the function call and through the "mask to see" the "mask to see" compiler's optimization layer with a function called. Sometimes it is like this, but it is often not. If the function is not very frequently called, it is generally not seen that the overall execution time of the program is changed. In fact, the opposite situation is likely to occur: If the content of the function of the function is built, the corresponding caller's reference will be reduced, which means that the inner layer of the register when the processor is cached. When it is loop, the overall execution speed of the program is actually reduced.
Put this in the entire point of view, don't forget that most programs are not limited by the CPU. Perhaps the vast majority of common bottlenecks are I / O restrictions, including all things in the reaction time of network bandwidth, file or database processing.
d) Development speed, compilation speed. The most useful thing is that the inline code must be visible for the calling program, which means that the calling program must depend on the internal inline code. Details of the internal execution of other modules increase the union of the actual modules (however, it does not increase their theoretical combination, because the calling program does not use any internal information of any called program). Usually when FUNCTION changes, the calling program does not need to be recompiled (only the re-connect, and sometimes even this is not required). And when the inner function changes, the calling program must be recompiled. Finally, if you are paying attention to some way to improve efficiency, look at your algorithm and data structure ... they will bring you a comprehensive improvement in the order, although, the same procedures are the most optimized in the inline ( Note that "general") will only produce a relatively small effect.
Just say "now"
2. When should you be in, what method is used to inline a function?
Just like other optimizations: if there is a parser tells you, it is not a minute. The only moment you need to go immediately, when it is a very likely to keep an empty function, or when you absolutely forced to do this, for example, when you write a Non-Exported template.
As a result, inline us usually takes some things, if only the combination is added, and until you know what you will get, you will pay some things - that is, get a better return.
"But I am not always able to find a bottleneck." Will you think so? " Don't worry, you are not alone, because the vast majority of programmers are considering this problem at the same time or other time, but you are still wrong. Completely wrong. The programmer is not imagined with the real bottleneck in their code.
Usually only the signs of the trial (also known as an analysis) can help you tell you where the real urgent place. Ten eight9. If there is no analysis tool, the programmer cannot determine the most urgent bottleneck in his code. I have studied ten years in this field. I found this same anomalies with all the programmers I have worked or heard ... even if everyone and their young compatriots may claim to be on them. Will not appear until they have made faces. :-)
[Please pay attention to another reasons: Profilers (analyzer) is not good in determining that inline function should be made by inline.
What will I do with those calculating intensive tasks (such as digital [calculation] libraries)?
Some people like to write small, compact library code, such as advanced science and engineering digital libraries, and sometimes we can do suitable inline. However, those developers tend to make wise inline and tend to adjust later. Please note that writing a module, then compares the inline and non-inline performance is not a good idea, because all inline or all inline only is just a rough measure, can only tell you average ... It can't tell you which function can be beneficial (and how much each). Even in these cases, you typically use a parser, then optimize your program on the basis of its suggestions.
What is the ACCESSOR?
Some people speak the ACCESSOR function (such as X & Y :: f () {return myx_;}) is a reasonable exception, which should / embed it automatically. I understand their ideas, but be careful: at least all embedded code increases the coupling, so unless you know in advance, you may wish to make a decision after analyzing. After the code is stable, the parser may indicate that it is within the time: a) You know what you do; and b) you avoid all coupling and possible in the end of the project development cycle. Compilation consumption (referring to each time the compiler is used for each process of inserting all of its code). This account is coming,. . . In summary
From the gotw coding standards:
- Avoid Inline or Detailed Tuning Until Performance Profiles Prove The NEED (CLINE95: 139-140, 348-351; Meyers92: 107-110; Murray93: 234-235; 242-244)
- Corollary: in General, Avoid Inline (lakos96: 631-632; murray93: 242-244)
[Note That this delibely Says "NEVER" (NOT "NEVER") and That these Same Coding Standards do encourage prior inlining in one or two very restricted situations.
CLINE95: Marshall Cline And Greg Lomow. "C FAQs" Addison-Wesley, 1995
Lakos96: John Lakos. "Large-Scale C Software Design" Addison-Wesley, 1996
Meyers92: Scott Meyers. "Effective C " Addison-Wesley, 1992
Murray93: Robert Murray. "C Strategies and Tactics" Addison-Wesley, 1993
