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?

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.

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

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.

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.

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.