Inline functions

When I run the following code on my system, the inline function virtually always runs slower than the non-inline function. Why is this?

Code:

#include <iostream>
#include <ctime>
using namespace std;

inline void f1()
{
	int n = 0;
	for (int i = 0; i < 100; i++)
		n += 10;
}

void f2()
{
	int n = 0;
	for (int i = 0; i < 100; i++)
		n += 10;
}

int main()
{

	clock_t start;
	clock_t end;
	clock_t duration;

	cout << "Running inline function f1()..." << endl;
	start = clock();
	for (int i = 0; i < 1500000; i++)
		f1();
	end = clock();
	duration = end - start;
	cout << "Time elapsed: " << duration << " ticks." << endl;

	cout << "Running function f2()..." << endl;
	start = clock();
	for (int i = 0; i < 1500000; i++)
		f2();
	end = clock();
	duration = end - start;
	cout << "Time elapsed: " << duration << " ticks." << endl;

	system("pause");
	return 0;
}

Originally Posted by Sharke

When I run the following code on my system, the inline function virtually always runs slower than the non-inline function. Why is this?

Considering that a compiler might not inline despite the suggestion, especially due to the presence of a loop...

Maybe it's slow because you called it 1.5 million times.

Originally Posted by laserlight

Considering that a compiler might not inline despite the suggestion, especially due to the presence of a loop...

Ah, I did not know that inline functions were compiler suggestions. Having said that, I get similar results if I copy and paste the function body in place of the function call. It's not slower than the function call every time, but most times. This surprises me.

Originally Posted by whiteflags

Maybe it's slow because you called it 1.5 million times.

1.5 million, 1.5 thousand......it's the comparison with the non-inline function I was interested in.

Originally Posted by Sharke

Having said that, I get similar results if I copy and paste the function body in place of the function call. It's not slower than the function call every time, but most times. This surprises me.

Maybe it is just "luck". You could compare assembly output to see what is happening.

I assume you're compiling WITHOUT optimization? Because any decent optimizing compiler will optimize that entire thing to nothing, since the function has no side effects, and returns no value.

Here's what I get:

Code:

scott@scott-intel-mini-ubuntu:/tmp$ g++ -O3 -o timer timer.cpp
scott@scott-intel-mini-ubuntu:/tmp$ ./timer
Running inline function f1()...
Time elapsed: 0 ticks.
Running function f2()...
Time elapsed: 0 ticks.
sh: pause: not found

As opposed to without optimization:

Code:

scott@scott-intel-mini-ubuntu:/tmp$ g++ -O0 -o timer timer.cpp
scott@scott-intel-mini-ubuntu:/tmp$ ./timer
Running inline function f1()...
Time elapsed: 620000 ticks.
Running function f2()...
Time elapsed: 560000 ticks.
sh: pause: not found

Looking at the assembly code generated without optimization, neither call is being inlined, and the assembly code for f1() and f2() is identical. So why the difference? I can't explain it, honestly, but I doubt it has anything to do with inlining, since neither function is actually being inlined.

Your compiler may differ, of course.

Sharke,

Pay close attention to brewbuck's point.

For example, if n were not local (so it's preserved between calls), and then PRINTED at the end, the compiler would probably not be able to optimize the calls into nothing.

Also, timing differences:

I've found that the precision of the clock is low compared to the microscopic inspection this kind of research is doing. On occasion I've observed that the order in which the calls are made is the difference ( that is, reverse f1 with f2 in main and see if that changes your observation ).

Due to the way you've written the code, some compilers might inline f2 even though you didn't ask for it. This is especially true of the "any suitable" option.

Also, ask yourself what are you timing here?

1.5 million function calls -
or the loop of 100 items inside each call?

1.5 million loop of the outer call -
or the repetitions of the interior loop of 100?

(the latter is an inline version)


Sometimes all you're going to do inside the function is 100 items in a loop - I know.

But at a ratio of 1.5 million to 100, your timing relates as much to the performance of the CPU's cache as it does the ability to increment in a loop. That performance will not be stable! It is interrupted by other processes the OS is performing, which will destroy any predictability in the timing of your tests.

So, generalize your test results. Test several runs, different orders, quiet the machine (stop services) - if you really want to know such microscopic differences between performance of any few different approaches.


A quick example that irks me on this kind of research.

In Don Knuth's work, an example loop optimization is discussed that uses "goto". It is often touted as the reason "goto" is valuable (there's a long standing argument about the 'proper-ness' of goto). A simple loop through an array searching for a match (array of integers). The "goto" loop is about 6 % to 8 % faster, but not because of goto. The "goto" fans miss the point of the example (the code in the citation is pascal style pseudo-code).

The point of the loop isn't that goto was used, but that the loop isn't indexed by 1, it is indexed by 2, and two adjacent elements in the array are tested inside the loop instead of one.

The results are identical if you perform a 'standard' for or while loop in C with the same incremental adjustment, with the sole exception of extremely small datasets.

Incrementing the loop by 4, and testing for adjacent entries in the array at once within the loop, yields another incremental performance increase.

In my own tests, demonstrating that the "goto" version performed exactly as the "standard loop" versions in C was maddening. Measurements varied, the order in which the tests gave one or other test a 1% result advantage - more telling, if I ran the same tests interleaved (that is, test1, test3, test2, test3, test1, test 2 ) I'd get different timings on exactly the same values and conditions.


This Knuth example relates to your test and inquiry somewhat, BTW.