Shouldn't inline functions be faster?

This topic is 2030 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

So there is an exercise that says I should create a program to measure which function is faster,a normal one,or a inline one.

Here's the code:


#include <iostream>
#include <string>
#include <assert.h>

#include <ctime>
using namespace std;

clock_t t;
inline void f1(){
t=clock()-t;
if(t!=0)
cout << "f1 " << t << endl;
}

void f2(){
t=clock()-t;
if(t!=0)
cout <<"f2 " << t << endl;
}
int main() {
for(int i = 0;i<10000;i++){
t=clock();
f1();
}
for(int i = 0;i<10000;i++){
t=clock();
f2();
}

}


The problem is f1 appears 4 times and f2 appears 2 times.As you can see I set the functions so they'll show text only if the time difference is bigger than 0.

Why does the inline function get executed slower?! Shouldn't it be faster?

Share on other sites

It should be faster, not by much but a little, if you call them lots of times you should see a slight increase in performance.  However the compiler is free to chose to inline or not to inline, whether you declare it as inline or not.  For example with optimisations on, your compiler may inline functions that you didn't declare inline.  And also choose to not inline if you declared as inline.

That said, your clock probably doesn't have the accuracy needed for this test.  Try using c++11 high_precision_clock instead ( <chrono> ).  Or if not using c++11, try win32 clock QUERY functions.

Edited by EddieV223

Share on other sites

That said, your clock probably doesn't have the accuracy needed for this test. Try using c++11 high_precision_clock instead ( ). Or if not using c++11, try win32 clock QUERY functions.

If you're using Visual Studio 12 then high_precision_clock won't work unless they've fixed it in one of the updates. It shipped with a placeholder version that used a low-resolution clock. If you're on Windows/Visual Studio 12, you should use QueryPerformanceCounter instead.

Somewhat related are the contents of this thread, in particular my last post and my post preceding it touch a little bit on why inlining and other micro-optimizations aren't so simple to reason about, and from there you can infer why its a good thing that the inline keyword is only a hint to the compiler, rather than a direct command.

Share on other sites

I did my own test a while back on inlining functions, compiled a similar test exe, and disassembled it to look at the actual output from the compiler - only to find that the code, for both functions, and for calling them, was identical.. eg: there was no discernable difference between using inline and not inline at the machine code level.. All of this I assume is the result of what everybody is saying about it here.

So, I just #define function-like macros to produce virtually the same result as inlining functions. At least, from what I've read, it's virtually the same as inlining functions. Either way, it works how I want it to at the machine level.

Share on other sites
If you are using Microsoft visual studio you can force use '__forceinline' keyword, meanwhile 'inline' just gives the compiler a "hint". Inlining a function removes the call/ret overhead generated by compiler, but creates a larger executable image. The only time i use inlining is small tight loops where the overhead would cost too many cpu cycles, otherwise i rely on the compiler to make the right decision.

Share on other sites

If you are using Microsoft visual studio you can force use '__forceinline' keyword

Actually you can't. Even __forceinline is just a strong suggestion. From the MSDN documentation on __forceinline:

The compiler treats the inline expansion options and keywords as suggestions. There is no guarantee that functions will be inlined. You cannot force the compiler to inline a particular function, even with the __forceinline keyword.

Share on other sites

Function inlining can cost you performance because it increases the code size an thus the the strain on the I-cache.

However if used correctly it can significantly increase the performance for two reasons:

1. The compiler can optimize across the boundaries of the function. In your case you won't be seeing this, because there is virtually nothing outside the function except for the loop.

2. You don't need the the instructions for calling the function, passing parameters, creating a stack frame, etc. You only see a benefit from this, if this overhead is actually a large percentage of what the function does. This is typically the case for getters and setters which would boil down to about 1 instruction if not for that overhead. However in your case, you are doing a syscall in that function worth a couple of thousand instructions, so the overhead of not inlining is insignificant.

Bottom line, in the scenario you chose, inlining should not give you any visible performance advantage.

Share on other sites

You shouldn't treat inline as a performance directive.  Much like the old auto and register keywords, its initial use is pretty much depricated.  Rather think of it in terms of a linkage directive, like extern, or static.  The inline keyword allows you to define a function in the header, and it quite useful in that regard.  As far as performance concerns, modern compilers with global optimizations do not need a hint to know when or when not to considering inlining.

1. 1
2. 2
Rutin
18
3. 3
4. 4
5. 5

• 9
• 14
• 9
• 9
• 9
• Forum Statistics

• Total Topics
632921
• Total Posts
3009211
• Who's Online (See full list)

There are no registered users currently online

×