The compiler is unable to conduct inlining in two instances. It just accepts the inline definitions and produces space for the function in the same way it does for a non-inline function in these circumstances. The linker is advised to overlook multiple definitions if it has to do this in many translation areas (which would ordinarily result in a multiple definition error).
If the function is too intricate, the compiler will not be able to inline it. This depends on the compiler, but at the point when most compilers surrender, the inline is unlikely to save users any time.
In general, any looping is too difficult to extend as an inline. Looping definitely takes a lot longer inside the function than the overhead of the function call, if one thinks about it. The compiler will probably have no issue inlining the function if it is just a collection of basic statements.
If there are several statements, the overhead of the function call will be much lower than the cost of executing the body. And keep in mind that when one executes a big inline function, the full function body is put instead of each call, so one might easily end up with code bloat without seeing any performance gains.
If the compiler needs to generate an address, it will allocate memory for the function code and utilize the address. The compiler will very probably inline the code if an address isn't required. If the function's address is given implicit or explicit, the compiler cannot execute inlining.
It's important to understand that an inline is merely a suggestion to the compiler; the compiler is not required to inline anything.
A decent compiler will inline small, basic routines, but too intricate inlines will be ignored. This will give the user the desired results: real function call semantics combined with macro efficiency.
Increase function size to the point where it won't fit in the cache, resulting in many cache misses.
If the number of variables that will use the register rises after inlining, the overhead on registered variable resource use may increase.
It may result in compilation overhead since all calling locations will be compiled if code inside an inline function is changed.
If used in a header file, it will increase the size of the file and may make it illegible. Using too many inline functions can result in a higher code size, which can cause memory thrashing. As the number of page faults increases, your program's performance suffers. It is ineffective in embedded systems where big binary sizes are undesirable due to memory limits.
As the body of an inline function is added in the place of a function call, the executable file size grows, and more memory is required. Not suited for recursive function definitions that are excessively long and intricate.
As we have seen disadvantages / limitations of using inline function now let’s see some advantages of inline function.
- It does not necessitate the overhead of invoking functions.
- It also reduces the overhead of variables being pushed and popped on the stack during function calls.
- It also reduces the overhead of a function's return call.
- It uses an instruction cache to promote the locality of reference.
Because inline functions produce less code than function calls outline and return, they may be beneficial for embedded devices (if they are small).
- The speed with which a program is executed increases. It is possible to generate efficient code. The program's readability improves.