This question already has answers here:
Inline function v. Macro in C -- What's the Overhead (Memory/Speed)?
(9 answers)
Closed 6 years ago.
I often have this kind of statement in my code :
(b != 0) ? a / b : a
In terms of speed and best C++ pratice, is it better to do a function
float divifnotzero(a,b) { ... return ... }
or a preprocessor macro like this ?
#define divifnotzero(a,b) ((b!=0)?a/b:a)
The pre-processor is just going to replace the code wherever you use the macro, so there is no difference there. As for a function, your compiler will almost certainly inline it, so again there should be no difference in speed. So, given that I would go with a function for readability.
Preprocessor macros inline any code you put in them. A function call allows you to reduce the size of the executable at the expense of some slight overhead. Based solely on that, in this instance you would want to use a preprocessor macro.
In practice, functions can be inlined just like preprocessor macros with the inline keyword, which gets rid of the overhead. The compiler can generally decide on whether or not to inline a function itself; one like this would almost certainly have that happen. Go for the function call, unless you're specifically compiling the program without optimizations while still valuing speed.
Related
This question already has answers here:
"inline" keyword vs "inlining" concept
(2 answers)
Closed 6 years ago.
I always read that inlined functions should be short functions because otherwise the executable gets bloated with too many copies of the same code.
However, I try to refactor my code and write small helper functions, which are often not so small (20-30 lines) and often only used by exactly one other function, e.g. to avoid the do{...}while(false); idiom.
Hence my questions:
Wouldn't it be a good idea to inline a long function, if it is only used by exactly one other function regardless of how long it is? The size of the executable would be the same, and one function call would be saved.
Would a good compiler consider this? Or is the length a strong criterion to not-inline a function. Does this depend on whether I explicitly write inline, as compilers seem to ignore this mostly?
Keep your functions small in 40-60 code lines (excluding comments/new-lines).
Pass less number of parameters into functions, if there are many parameters to be passed, pack them into structure, and pass the struct by reference. This reduces call stack space.
Don't nest the functions too much. Max 4-5 nesting level is just good (switch, while, if etc.). If it is getting more than that, try to refactor within function by return, changing conditions, flow-path etc.
Don't pass large objects by value, pass them by reference.
Make methods as static if they aren't using any data members - to avoid this being pushed and popped from call stack.
Don't over optimize any code - let the compiler do it for you. Optimized build will take time to optimize the code in best manner for target platform.
Do code instrumentation, and use/deploy the instrumented code. Code instrumentation will change the flow of code so that program runs faster. For example if(rarely_true) Dothis(); else DoThat(); will be reversed in code instrumentation if instrumentation finds that raraly_true is mostly false. This is simplest example.
This question already has answers here:
Inline functions vs Preprocessor macros
(14 answers)
C/C++ macros instead of const [duplicate]
(4 answers)
Closed 7 years ago.
What is the most significant difference of these two max operations? Which one do
you prefer to use in your system, and why?
#define max(a,b) (a)<(b)?(b):(a)
int max (const int a, const int b) { return (a) < (b) ? (b) : (a); }
I am trying to see if I am on the right track for the above question. My first thought is obviously that the #define indicates a preprocessor directive, or MACRO, named "max". Therefore, anywhere "max" is encountered in the program, it will be replaced with the defined value of this macro. Macros also dont require any memory allocation, so we can expect faster execution times.
The const keyword, on the other hand, does require memory allocation, and is not able to be changed by the executing program. The overall consensus through my notes and some online sources seems to be that macros are more efficient/faster since they do not require the memory allocation. Therefore, it would seem I would prefer to use macros for their speed advantages.
Basically my question is, am I nailing the main differences between these two? Or am I missing something major?
This question already has answers here:
When to use the inline function and when not to use it?
(14 answers)
Closed 7 years ago.
If a function is only used in one place and some profiling shows that it's not being inlined, will there always be a performance advantage in forcing the compiler to inline it?
Obviously "profile and see" (and in the case of the function in question, it did prove to be a small perf boost). I'm mostly asking out of curiosity -- are there any performance disadvantages to this with a reasonably smart compiler?
No, there are notable exceptions. Take this code for example:
void do_something_often(void) {
x++;
if (x == 100000000) {
do_a_lot_of_work();
}
}
Let's say do_something_often() is called very often and from many places. do_a_lot_of_work() is called very rarely (one out of every one hundred million calls). Inlining do_a_lot_of_work() into do_something_often() doesn't gain you anything. Since do_something_often() does almost nothing, it would be much better if it got inlined into the functions that call it, and in the rare case that they need to call do_a_lot_of_work(), they call it out of line. In that way, they are saving a function call almost every time, and saving code bloat at every call site.
One legitimate case where it makes sense not to inline a function, even if it's only called from a single location, is if the call to the function is rare and almost always skipped. Keeping the instructions before the function call and the instructions after the function call closely together in memory may allow those instructions to be kept in the processor cache, when that would be impossible if those blocks of instructions were separated in memory.
It would still be possible for the compiler to compile the function call as if using goto, avoiding having to keep track of a return address, but if the compiler has already determined that the function call is rare, then it makes sense to not pay as much time optimising that call.
You can't "force" the compiler to inline it, unless you are considering some implementation-specific tools that you have not mentioned, so the question is entirely moot.
If your compiler is already not doing so then it has a reason.
If the function is called only once, there should be no performance disadvantages in inlining it. However, that does not mean you should blindly inline all functions. For example, if the code in question is Linux kernel code and you're using the BUG_ON or WARN_ON statement to print a stack trace, you don't get the full stack trace which includes the inline function. Instead, the stack trace contains only the name of the calling function.
And, as the other answer explained, the "inline" doesn't actually force the compiler to inline the function, it just is a hint to the compiler. However, there is actually an attribute __attribute__((always_inline)) in GCC which should force the compiler to inline the function.
Make sure that the function definition is not exported. If it is, it obviously needs to be compiled, and that means that if your function is big probably the call will not be inlined. (Remember, it's the call that gets inlined, not the function. A function might get inlined in one place and called in another, etc.)
So even if you know that the function is called only from one place, the compiler might not. Make sure to hide the definition of your function to the other object files, for example by defining it in the anonymous namespace.
That being said, even if it is called from only one place, it does not mean that it is always a good idea to inline it. If your function is called rarely, it might waste a lot of memory in the CPU cache.
Depending on how you wrote your function.
In some cases, yes!
void doSomething(int *src, int *dst,
const int loopCountInner, const int loopCountOuter)
{
int i, j;
for(i=0; i<loopCounterOuter; i++){
for(j=0; j<loopCounterInner; j++){
*dst = someCalculations(*src);
src++;
dst++
}
}
}
In this example, if this function is compiled as non-inlined, then compiler basically has no knowledge about the trip count of the two loops. This is a big deal for implementations that rely strongly on compile-time optimizations.
I came across a even worse case: compiler assumes loopCounterInner to be a large value and optimized for that case, but loopCounterInner is actually 3 or 5 so the best choice is to fully unroll the inner loop!
For C++ probably the best way to do it is to make them template variables, but for C, the only way to generate differently optimized code for different use cases is to inline the function.
No, if the code is a rarely used function then keeping it off the 'hot path' will be beneficial. An inline function will use up cache space [instruction cache] whether or not the code is actually used. Tools like LTCG combined with Profile Guided optimisation (in the MSFT world, not sure about Linux) go to great pains to keep rarely used code off the hot path and this can make a significant difference
I have a very long code, which is being called millions of time,
I have noticed that if I change all the macros into inline functions the code runs a lot faster.
Can you explain why this is? Aren't macros only a text replacement? As opposed to inline functions which can be a call to a function?
A macro is a text sustitution and will as such generally produce more executable code. Every time you call a macro, code is inserted (well, not necessarily, the macro could be empty... but in principle).
Inline functions, on the other hand, may work the same as macros, but they might also not be inlined at all.
In general, the inline keyword is rather a weak hint than a requirement anyway, compilers will nowadays judiciously inline functions (or will abstain from doing so) based on heuristics, mostly the number of pseudo-instructions.
Inline functions may thus cause the compiler to not inline the function at all, or inline it a couple of times and then call it non-inined in addition.
Surprisingly, not inlining may actually be faster than inlining, since it reduces overall code size and thus the number of cache and TLB misses.
This will depend on the particular macro and function call that you are using. A particular macro can actually compile to a longer set of operations than the inline function. It is often better not to use a macro for certain processes. The inline function will allow the compiler to type check and optimize the various processes. Macros will be subject to a number of errors and can actually cause various inefficiencies (such as by having to move variables in and out of storage).
In any case, since you actually see this happening in your code, you can tell that the compiler is able to optimize your inline code rather than blindly put in the text expansion.
Note that a google search 'macros vs inline' shows a number of discussions of this.
Apart from forcing inlining, macros can also be detrimental to speed if they are not carefully written not to evaluate their arguments twice. Take for example this little function-like macro and its inline function equivalent:
#define square(x) ((x)*(x))
inline long square(long x) { return x*x; }
Now, when you call them with a variable square(foo), they are equivalent. The macro vesion expands to ((foo)*(foo)), which is one multiplication just like the function if it's inlined.
However, if you call them with square(expensiveComputation(foo)), the result of the macro is, that expensiveComputation() is called twice. The inline function, in contrast, behaves like any function: its argument is evaluated once before the body of the function is executed.
Of course, you could write the macro using the gnu extension of compound statements (see http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html for documentation on this) to avoid double evaluation like this:
#define square(x) ({ \
long square_temp_variable = (x); \
square_temp_variable*square_temp_variable; \
})
But this is a lot of hassle, and it makes the code unportable. So, better stick with inline functions.
at general it is a good advise to replace function style macros by inline functions wherever this is possible.
not only you ged rit of some nasty traps a = MIN(i++, 50) for example you also gain typesafety and as already stated in some comments you avoid multiple evaluation of arguements, that may have very bad influence on performance.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Inline functions vs Preprocessor macros
what is concept of Inline function and how it is differ from macro?
inline unsigned int getminutes( unsigned int seconds )
{
return( seconds / 60 );
}
#define GetMinutes(seconds) (seconds) / (60)
To be honest I'd ask which one is faster, but I've seen so much on S.O that asking which one is better would grant me me knowledge. (Yes! I'm a knowledge hunter)
Never use a macro if you can use an inline function to achieve the same. The compiler is going to generate exactly the same code for both of the solutions you provided, assuming you are using a fairly decent one.
Of course there is no guarantee that inline functions will actually be inlined, but in these cases, if your compiler can't inline that function, then it's probably a really bad one.
Just don't use macros unless you really need to(header guards, do repetitive stuff, etc). Macros are evil in several ways, you can read a lot about that if you search for information online.
I guess the macro will be faster if you consider that inline is not guaranteed by the compiler to be used. If the function is not inlined, then you have the overhead of a function call.
The macro will be expanded in place by the preprocessor, so it's always going to be inline.
The macro is also not type safe and has global scope.
Functions are preferred.
With a good optimizing compiler the performance will be identical. The difference is that the inline function is more or less a suggestion to the compiler. Although the compiler should in most cases honor the suggestion, the macro version will force the compiler to inline the code.
As an aside, your macro should be written ((seconds) / 60) to make sure the intended grouping is used in all cases.
Unfortunately, which is faster is one of those cases where the only way to know is to profile. I suspect, however, that the result is the same in typical release build settings.
Which is better, however, I'd say the inline function. Easier to debug. Safer than a macro.
I avoid macros except where absolutely necessary. I think of them as compile-time find-and-replace. I consider find-and-replace to be extremely dangerous at worst. I actually wrote a post or two about why I dislike #define macros so intensely...
Another word of advice I run on: The compiler knows better than you. The macro will force inline, even if it's actually not good for performance. inline will suggest it as a candidate for inlining, but may not inline if it doesn't meet criteria to be inlined.