a. That is a terrible way of measuring performance:

• clock() has bad granularity
• Even if it had, the overhead of calling clock() so often in such tiny code completely obliterates any difference between the inlined & non-inlined version. (in other words, you're just reading noise)
• What happens inside std::cout can affect your code, stuff like buffer flush & buffer being full can affect the test results (edit: specially since cout's state is not the same between f1 & f2)

b. Inlining isn't always faster:

• It produces bigger code, which can trash the L1 cache (not your case though)
• There is an important branch in your code, the CPU's branch predictor was warmed up by f1's iteration, so it predicts better what is going to happen in f2. Also branch predictors may or may not be better at predicting your result depending on the call stack (completely architecture dependant); so it may be predicting better the non-inlined version. My bets the warming up is what's causing your strange results.

c. What SiCrane said, inline is a hint, not a guarantee. You have to look at the actual generated assembly to see what's inlined and what's not (it may be possible your non-inlined function got actually inlined).
Although, I digress with SiCrane in that MSVC 100% ignores the keyword. Coincidentally a week ago while playing with VS 2008 I saw the compiler was inlining a function only when I wrote the "inline" keyword. The operation going on was moderate (not too short, not too big), so I guess the MSVC's decision about whether inline it was on the edge. 99% of the times though, it just ignores me.

Read MSDN's documentation on inlining, there are some cases where even __forceinline can't be inlined, just to quote:

Even with __forceinline, the compiler cannot inline code in all circumstances. The compiler cannot inline a function if:

• The function or its caller is compiled with /Ob0 (the default option for debug builds).
• The function and the caller use different types of exception handling (C++ exception handling in one, structured exception handling in the other).
• The function has a variable argument list.
• The function uses inline assembly, unless compiled with /Og, /Ox, /O1, or /O2.
• The function is recursive and not accompanied by #pragma inline_recursion(on). With the pragma, recursive functions are inlined to a default depth of 16 calls. To reduce the inlining depth, use inline_depth pragma.
• The function is virtual and is called virtually. Direct calls to virtual functions can be inlined.
• The program takes the address of the function and the call is made via the pointer to the function. Direct calls to functions that have had their address taken can be inlined.
• The function is also marked with the naked __declspec modifier

Cheers
Dark Sylinc

Inspecting the compiled assembler code should be the first step of any performance test: if the code is identical there is nothing to measure.
With GCC, you can simply pass option -S to get assembler code.

You should also test completely separate programs, not one program with two functions: the compiler could do something different because there are two identical functions in the same compilation unit.
The test program can be written as

INLINESPEC void testFunction(){
...
}

int main (){
...
testFunction()
...
}

You can define INLINESPEC as "inline", an empty string, or the fancy compiler-specific attributes through compiler commandline options to get each variant.

To understand why inlining sometimes is faster and sometimes isn't you need to have a solid understanding of what a C++ compiler is doing under the hood and how your code is transformed into assembler. There can be quite a few surprises happening when you look at the assembler code of a particular function, as a single float divide can spawn SSE2 assembler if compiling with that option on, even in non vectorised code.

http://www.altdevblogaday.com/2013/01/05/cc-low-level-curriculum-part-10-user-defined-types/ the articles referenced in this link will give you a good explanation of what is going on under the hood if you want to know more.

Inspecting the compiled assembler code should be the first step of any performance test: if the code is identical there is nothing to measure.
With GCC, you can simply pass option -S to get assembler code.

You should also test completely separate programs, not one program with two functions: the compiler could do something different because there are two identical functions in the same compilation unit.
The test program can be written as

INLINESPEC void testFunction(){
...
}

int main (){
...
testFunction()
...
}

You can define INLINESPEC as "inline", an empty string, or the fancy compiler-specific attributes through compiler commandline options to get each variant.

Actually it shouldn't be this works for this case but if you find that your application is running slow the first thing you should do is run a profiler and find where the hotspot is in your application. Looking at the generated assembler is a last resort as a C++ compiler for an out-of-order CPU is better at optimising this then you are, on inline CPU's hand optimised assembler can be faster. Nowadays optimisations are more about data locality then about instruction level otimisations, hitting a cache miss is more costly than having a slightly unoptimised instruction order, especially on out-of-order CPU's. The compiler is not the only place where optimisations to your code happen even during runtime a modern CPU is reordering the way your instuctions are issued to the ALU and you have no control over this.

http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2 even though this presentation is mostly about Parallel programming in the first bit he tells you what happens after your code is compiled and run on a modren CPU and wich transformations it can apply to that code.