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.
Related
How can I force the inlining of a function, but define it in a C++ file ?
This is a question that's been asked in the past, for example here: Moving inline methods from a header file to a .cpp files
The answers there, in short, go as follows: "inline used to mean [remove function call overhead at the expense of .text size], now it means [relax ODR], so don't use inline for anything that's not ODR related, the compiler knows better".
I'm aware of that, however in my somewhat exotic case, I don't care about performance.
I'm programming an embedded device and, should someone break through the other layers of security, I want to make it as obnoxious as possible to reverse engineer this part of the code, and one thing this implies is that I don't want function calls (that aren't called numerous times anyway) to expose the function boundaries, which are natural delimitations of pieces of code that achieve something on their own.
However, I would also like to keep my code orderly and not have code in my header files.
I see that I can use __attribute((force_inline)) to force inlining, but then I get warnings if those functions don't have an inline attribute too: warning: always_inline function might not be inlinable [-Wattributes]
Suppressing the attributes warning is an option, but I'd rather only take it once I'm sure there are no clean way to do this.
Hence the question: how can I have a forcibly inlined function whose declaration is in a header, but definition is in a source file, without suppressing all attributes warnings ? Is that impossible ?
Inlining can only be asked. Sometimes a bit forcefully. But you can never guarantee that the function WILL be inlined finally - because reasons, sometimes quite obscure ones.
Here what's MSVC documentation says (I've highlighted the important parts):
The compiler treats the inline expansion options and keywords as suggestions. There's no guarantee that functions will be inlined. You can't force the compiler to inline a particular function, even with the __forceinline keyword. When compiling with /clr, the compiler won't inline a function if there are security attributes applied to the function.
C++ standard says:
No matter how you designate a function as inline, it is a request that the compiler is allowed to ignore: the compiler might inline-expand some, all, or none of the places where you call a function designated as inline.
GCC documentation is a bit less crystal-clear about non-inlinable functions, but cases exists anyway.
The only "real" way to force inlining is quite ugly, since it rely on inlining it before compilation... Yeah, old-style preprocessor macros. The Evil Itself. Or by using a dirty hack with a #include replacing the function call (and inserting C++ code instead)... It may be a bit safer than a macro, regarding double evaluations, but other side-effects can be even worse since it must rely on "global" variables to work.
Does it worth the pain? Probably not. In particular for "obfuscation", because it won't be as "secure" as you think it will be. Yes, an explicit function call is easier to trace. But it won't change anything: reverse engineering don't rely on that to be done. In fact, obfuscation is near never a good (or even working...) solution. I used to think that... a long, very long time ago. I proved to myself that it was near useless. On my own "secured" code. Breaking the code took me much less time than it took me to "protect" it...
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.
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.
I have a method like the one shown below.
Will the for loop always make the compiler for go the "inline request" ?
inline void getImsiGsmMapFrmImsi
(
const string& imsiForUEDir,
struct ImsiGsmMap& imsiGsmMap
)
{
for (int i = 0 ; (unsigned)i < imsiForUEDir.length() - 1 ; i++)
{
imsiGsmMap.value[i] = imsiForUEDir[i] - '0' ;
}
imsiGsmMap.length = imsiForUEDir.length() - 1 ;
}
You can specify "inline" and the compiler can ignore it if it feels like that.
Simply, no.
"inline" is just a hint to the compiler.
There are ways to force a compiler to inline something, but these ways are compiler-specific. Your code looks mobile to me, so here's some ways on some C++ compilers used on various mobile phone platforms:
Windows CE/ Windows Mobile VC++ ARM compiler uses the __forceinline keyword instead of the hint 'inline'.
A better compiler (i.e. makes faster output) for Windows CE/ Windows Mobile is cegcc, which uses the very latest GCC 4.4. In GCC, you write __attribute__((always_inline)) after the function name and before the body.
The bigger thing is if it's a good idea to inline this loop. I program mobile phones for a living, and they don't have much CPU budget generally. But I'd be really surprised if this loop is a bottleneck. Strip your program of all the 'inline' decorations and when you're approaching shipping, if the program is slow, profile it!
Some compilers allow 'profile guided optimisation' where they can make an instrumented binary that you run in a realistic way, and then they use the data so gathered to make a production binary where they make informed decisions about code speed vs code size in the various parts of your program to give the very best mix of both.
"No inlining for functions with loops" is probably a bit of some inline heuristic from some particular compiler. It doesn't apply universally.
Every compiler uses some heuristics to determine whether the function should be inlined or not, but normally every compiler uses its own ones. So, to say that a loop will have some universal effect on inlining is not correct. It won't. There's absolutely nothing in your function that would somehow fundamentally preclude inlining. Most modern compilers can easily inline this function, if they deem it reasonable or if you force them to do it.
Yes, some compilers offer non-standard declaration specifiers (or compiler options) that will actually force the inlining, i.e. override the heuristic analysis, except for a number of situation when the inlining is truly beyond the capabilities of the compiler. For example, many modern C/C++ compilers normally can't inline functions with variable number of parameters (variadic functions).
It also commonly believed that recursive function can't be inlined. In reality, in many compilers recursive functions can be inlined to certain fixed recursion depth, thus "compressing" the recursion.
I wonder if the inline keyword is even necessary anymore. Don't modern compilers mostly just ignore it and do whatever they think is best, anyway?
Most likely compilers will not inline a function with a loop, since what would be the point? If the code is looping, generally the cost of a function call will be unmeasurable noise compared to the looping.
But if a compiler wants to inline it (maybe the compiler is sophisticated enough to determine the loop bounds and can even unroll the loop), it's certainly allowed to.
But I wouldn't bet on it.
To summarize a previous answer I gave to this, the things you should watch out for when choosing a function for inlining are:
* local static variables
* loop constructs
* switch statements
* try/catch
* goto
* recursion
* and of course too much complexity (whatever that means)
Having said that as the other answers here point out, it's basically unspecified if the compiler inlines the function or not. 7.1.2/2 has:
A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected.
An interesting detail on this, is that the compiler would normally label the kind of behaviour that's involved here. For example: "it is unspecified" or "the behaviour is undefined" etc.