Inline function Advantages, Disadvantages, Performance and User Guidelines ?

Pages: 12
What is stored in swap space, then?

Wikipedia wrote:
Virtual memory is a computer system technique which gives an application program the impression that it has contiguous working memory (an address space), while in fact it may be physically fragmented and may even overflow on to disk storage.


Variables aren't always placed on the stack, anyway. Strings are placed in the .data section of the binary file. I would assume that the .data and .bss sections are placed in swap...
tajendra, thank you for some of the answers. I still have a problem with this quote,
"Now coming to embedded system point, most of the embedded system have constraint of memory size. So the first preferences is to keep binary size compatible to it i.e. memory optimization. After which one can apply optimization for performance.".


The problem is that it conflicts with other things. The idea of inlining is that you are giving a request to the compiler and it can choose to ignore the request if it is not sensible. Inlining replaces a jump and additional push/pop calls with the function being inlined. Therefore it shouldn't increase the binary size of only small inline functions exist. If a function is really big then the compiler should just ignore the inline request anyway. The confusion here is that I am personally not sure of what guidelines a compiler uses for making this determination and I wish that you would provide an example where the compiler will inline a large function and effectively increase the executable size.

If I were a compiler writer then I would want my compiler to analyze the function with the inline keyword and determine the number of bytes for the opcode and data to determine whether it makes sense to inline. One way to know whether the compiler has actually respected your request is to set breakpoints within the function. When a function is effectively inlined I usually can't set breakpoints within the inlined function body and have to turn on the display of assembly in order to step over that particular chunk of code.
3) Don't inline function with larger code size, one should always inline small code size function to get performance.


Its a guideline actually, which suggest dont inline function with larger code size.
Its true that inline keyword only request compiler but other way of unction inlining are also there.
As i mentioned inlining can be forced too with __forceinline with microsoft visual c++ compiler.
And as we are not aware of every compiler rules for inlining we cant predict whether it would get inlined or not. So its preferable not to use any kind of inlining with function having large number of lines.
What is stored in swap space, then?
Obviously, depends on implementation, but it's basically a probabilistic function. Pages that are used more often are less likely to end up being paged out. Of course, any page can be paged out. If you've ever left a large program (e.g. Visual Studio) idling for hours and then come back to notice a lot of disk activity and unresponsiveness when you start using it again, that's the program's memory being paged in. But the stack and code are used too often.

Variables aren't always placed on the stack, anyway. Strings are placed in the .data section of the binary file.
You mean the ones that are read-only and therefore not variables?

I would assume that the .data and .bss sections are placed in swap...
See the first paragraph.

So its preferable not to use any kind of inlining with function having large number of lines.
It makes no difference, anyway. The point of inlining is reducing the cost of making a function call. If the cost of the function itself is much larger than the cost of calling it, then whether it's inlined or not is irrelevant for execution time. In that sense, I agree that a large or expensive function shouldn't be inlined. Not because it increases code size, but because there's no benefit.
You mean the ones that are read-only and therefore not variables?

.bss and .data can store variables...

Uses Guidelines :-
1) Always use inline function when your are sure it will give performance.


Recently i got very good example showing immature use of inline function.
Suppose you have used inline function and for some reason compiler rejects it.
Well, when the compiler cannot inline a function, it generates a static definition of the function instead. In other words, the code for the function is generated just like the code for a static function. This means that every translation unit in which an inline function cannot be inlined will get its own copy of the function, which can increase the size of your program. Most compilers will report warnings when a function cannot be inlined. You should pay attention to these warnings to determine if some functions should not be inlined in the first place.

There is one more detail with inline functions that you should be aware of. Suppose you have chosen to use a local static variable in an inline function:

1
2
3
4
5
inline void foo()
{
static int index;
// ...
}



Next, suppose for some reason, the compiler cannot inline this function in several translation units. Each translation unit will then have its own static definition of foo(). But, this means that each version of foo() may also have its own copy of the static variable index! Clearly not what you want. So avoid putting static variables inside of non-member inline functions.
A random thought from me on that topic:

MSVC has "Whole Program Optimization" that can inline even when functions are not declared "inline". Means, the compiler can decide whether it is better to inline or not. That is an argument against explicit inlining.


Some general feedback to the article: Too much words. Maybe it's personal preferences. But I had a hard time to get most ideas just because there were so many words describing it. (just a random feedback. No offense.)

What about:

Advantages:
1) no function call overhead,
2) no push/pop on the stack for parameter and return values
3) increase locality of references by utilizing instruction cache.
4) apply for intraprocedural optmization. This is the most important one. The compiler can do better dead code elimination, branch prediction, induction variable elimination etc..
...

Ciao, Imi.
Last edited on
Immanuel feedback and suggestions are always welcome and you also rightly said personal preference. But still will keep your suggestion in mind.

Ya its very true MSVC has the wonderful feature of "Whole program optimization" which does inlining. But still if we talk about portable code we cant always rely on compiler. So for MSVC it will work but for other compiler it may not.
if we talk about portable code
You can talk either about portability or about inlining, but not both.
But still if we talk about portable code we cant always rely on compiler.

...
7) For recursive function most of the compiler would not do in-lining but microsoft visual c++ compiler provides...


*whistle and try to look innocent*....


;-)

Ciao, Imi.
Topic archived. No new replies allowed.
Pages: 12