Can I expect small functions to be inlined?

Question

I have a class that extracts data from a very large string of text.

Within this class I have a lot of very simple character matching. Despite indentation, spacing and comments, this becomes rather difficult to read.

I would thus like to move these little blocks of code into individual functions, which would greatly improve readability.

Now my question is if I can expect a modern compiler to inline 5-liners like this:

void f(page& p, size_t& index) // variable 'data' is class member
{
    p.id = 0;
    while(data[++index] != '<') {
        p.id *= 10;
        p.id += static_cast<uint>(data[index]) - 48;
    }
    index += 23;
}

The parent function will run millions of times, so if calling ~7 of these 'snippet' functions adds measurable overhead, I'd like to ensure they get inlined.

Is the inline keyword still considered good practice?

inline void f(page& p, size_t& index);

Should I trust the infinite wisdom of the compiler?

Answer 1

Is the inline keyword still considered good practice?

In C and C++, a function should only be defined in one Translation Unit (roughly equivalent to .c or .cpp file). There are only two exceptions:

• functions marked inline
• class methods defined in the class body (implicitly considered inline then)

That is inline: it means the definition is inline, and has no bearing at all on whether the function will be inlined at the call site.

Should I trust the infinite wisdom of the compiler?

I understand it's a "joke" but the wisdom of the compiler is only equal to that its developers taught to it. You should in general have a relative degree in confidence in your compiler (you are trusting it with your money, after all) but when it comes to performance at some point you will need to measure if it really matters.

---

Now, onto the specific function involved:

• yes it is likely to be inlined
• the effect of inlining it will depend on the average length of the while loop, the longer the loop runs, the less overhead the function call involves anyway

Oh, and for fun, on the Mill CPU (still being prepared) a function call has about the same cost as a branch (and thus a loop run); therefore, do remember that optimizations are platform dependent, even if you force inlining (with specific attributes) you may well shot down the performance on platforms you did not measure on.

Answer 2

You have a reasonable expectation of small functions being inlined if you use the inline keyword when defining the prototype, however dependant on optimisations and compilation switches it may not (it is merely a polite request to inline), however you can force it by using a prototype like:

inline void myInlineFunc() __attribute__((always_inline));

Which will in gcc force it to inline the function. In visual studio the same forcing can be done via:

__forceinline void myInlineFunc() __attribute__((always_inline));

References:

gcc

Visual Studio 2013 2012 2010 2008 2005 .net 2003

Let me know if that helps or if you need more info:)

Answer 3

Is the inline keyword still considered good practice?

Personally I would split monolithic code into well named inline functions where possible.

Should I trust the infinite wisdom of the compiler?

No, check for yourself. Whether it will inline or not will depend on your compiler and the options you have selected. For example with VS you have the option of whole program optimization as well as it being able to automatically inline any suitable functions. Pop a breakpoint in the function, enable mixed code and assembly and you should be able to see if it has inlined or not. Bear in mind that the compiler could decide it's not a good idea to inline it (eg speed/size) and if you decide to force inline, then make sure to profile both to ensure it is actually faster.

Answer 4

Since you don't really care about inlining, but about speed, you might consider making the code faster. For example, by making it use local variables instead of references, which are necessarily stored in memory. Again, make the change then measure the difference.