Are functors actually faster than pointers to functions?

According to Scott Meyers, one area where C++ shines over C is that function objects are faster than function pointers. He says this is because function objects are inlined, which increases speed.

I have two questions about this:

1. How can we verify that function objects are, in fact, inlined? Can we verify this in practice?

2. Does the inlining of function objects depend on the compiler we use, or do all compilers behave like this?

The C++ and C standards leaves a bunch of freedom to compilers. Compilers are free to count to 1 billion between every instruction, or only do so if an integer has a prime value in it.

Decent "real" compilers don't do this. This is a quality of implementation issue.

Inlining function objects into something like std::sort is something that every real compiler does. It is exceedingly easy to detect what needs to be inlined in those cases, because the type information carries with it the code needed to be inlined.

Doing so with a function pointer is harder. Doing so with a function pointer where everything has been converted to void* or char* pointers is even harder.

The effect of this is that, in practice, a C-style call to qsort vs a C++-style call to std::sort can result in an large advantage for std::sort.

qsort is roughly 2x slower than std::sort, as shown here, in a ridiculously simple situation of sorting randomly arranged integers.

Inspecting the actual assembly code output is mainly a detail, and it is a lot of work for little return. Taking concrete real-world examples gives you an idea of how big the impact really is.

All 3 of clang, gcc and MSVC where able to make std::sort be significantly faster than their qsort. And as this is an easy optimization, while optimizing function pointers into inline calls is not, you'd expect less major compilers to be no better than this at qsort.

> 1. How can we verify that function objects are in fact inlined? Can we verify this in practice?

Sure, inspect the finally emitted assembler code.

> 2. The inlining function objects depends on the compiler we use, or all compilers behave like that?

It heavily depends on compiler implementation and optimization level used.
So no, there's no guarantee particular compilers (linkers) behave so.

Calls through function pointers cannot be inlined though.

---

> According to him, function objects are inlined, so there is an increase in speed.

IMO "function objects are inlined" should better read (or heard, I don't know where that cite is from):

>> function objects can be inlined while calls through function pointers cannot.

Yes, function objects might lead to faster code. But the only way to ensure that is to benchmark.

1. The documentation says: "GCC may still be unable to inline a function for many reasons; the -Winline option may be used to determine if a function has not been inlined and why not."

2. Of course it will depend on compiler, version, flags, etc. Sometimes inlining can be counter-productive (code bloat etc.), so each compiler has its own set of rules to decide whether a function should be inlined. By the way, the inline keyword is only a hint, and some libraries such as eigen have a hard time to enforce inlining.