虚函数与函数指针 - 性能？

Question

Are C++ virtual functions called on a polymorphic base class just as fast as calling a C-style function pointer? Is there really any difference?

I'm considering refactoring some performance-minded code that utilizes function pointers and change them over to virtual functions in polymorphism.

Answer 1

I'd say most of the C++ implementations work similar to this (and probably the first implementations, that compiled into C, produced code like this):

struct ClassVTABLE {
    void (* virtuamethod1)(Class *this);
    void (* virtuamethod2)(Class *this, int arg);
};

struct Class {
    ClassVTABLE *vtable;
};

Then, given an instance Class x , calling the method virtualmethod1 for it is like x.vtable->virtualmethod1(&x) , thus one extra dereference, 1 indexed lookup from the vtable , and one extra argument (= this ) pushed onto the stack / passed in registers.

However the compiler probably can optimize repeated method calls on an instance within a function: since an instance Class x cannot change its class after it is constructed, the compiler can consider the whole x.vtable->virtualmethod1 as a common sub-expression, and move it out of loops. Thus in this case the repeated virtual method calls within a single function would be equivalent in speed to calling a function via a simple function pointer.

Answer 2

Are C++ virtual functions called on a polymorphic base class just as fast as calling a C-style function pointer? Is there really any difference?

Apples and oranges. At a miniscule "one vs. one" kind of level, a virtual function call involves slightly more work as there's an indirection/indexing overhead to get from vptr to vtable entry.

But a Virtual Function Call Can Be Faster

Okay, how could this be? I just said a virtual function call requires slightly more work, which is true.

What people tend to forget is to try to make a closer comparison here (to try to make it a little less apples and oranges, even though it is apples and oranges). We typically don't create a class with just one virtual function in it. If we did, then performance (as well as even things like code size) would definitely favor a function pointer. We often have something more like this:

class Foo
{
public:
    virtual ~Foo() {}
    virtual f1() = 0;
    virtual f2() = 0;
    virtual f3() = 0;
    virtual f4() = 0;
};

... in which case a more "direct" function pointer analogy might be this:

struct Bar
{
     void (*f1)();
     void (*f2)();
     void (*f3)();
     void (*f4)();
};

In this kind of case, calling virtual functions in each instance of Foo can be considerably more efficient than Bar . It's due to the fact that Foo only needs to store a single vptr to a central vtable which is being accessed repeatedly. With that we get improved locality of reference (smaller Foos and ones that can potentially fit better and in number into a cache line, more frequent access of Foo's central vtable).

Bar , on the other hand, requires more memory and is effectively duplicating the contents of Foo's vtable in each instance of Bar (let's say there are a million instances of Foo and Bar ). In that case, the amount of redundant data inflating the size of Bar will often significantly outweigh the cost of doing slightly less work per function pointer call.

If we only need to store one function pointer per object, and this was an extreme hot spot, then it might be good to just store a function pointer (ex: it might be useful for someone implementing anything remotely resembling std::function to just store a function pointer).

So it's kind of apples and oranges, but if we're modeling a use case anything close to this, the vtable kind of approach which stores a central, shared table of function addresses (in C or C++) can be considerably more efficient.

If we're modeling a use case where we just have one single function pointer stored in an object vs. a vtable which has only one virtual function in it, then the function pointer would be slightly more efficient.

Answer 3

It is UNLIKELY you'll see much of a difference, but like all these things, it's often the small details (such as the compiler needing to pass a this pointer to a virtual function) that can cause differences in performance. The virtual function itself is a function pointer "under the hood", so you probably get pretty similar code in both cases, once the compiler has done its thing.

It sounds like a good use of virtual functions, and if someone objected and said "there will be a performance difference", I'd say "prove it". But if you want to avoid having that discussion, make a benchmark (if there isn't one already) that measures the performance of the existing code, refactor it (or some part of it) and compare the results. Ideally, test on a couple of different machines, so that you don't get results that work better on YOUR machine, but not so good on some other types of machines (different generations of processors, different manufacturer or processor, etc).

Answer 4

A virtual function call involves two dereferences, one of them indexed, ie something like *(object->_vtable[3])() .

A call via a function pointer involves one dereference.

A method call also requires passing a hidden argument to be received as this .

Unless the method body is practically empty and there are no arguments or return values you are most unlikely to notice the difference.

Answer 5

The difference between a function pointer call and a virtual function call is negligible unless you already measured that the above is a bottleneck.

The only difference is:

• a virtual function has a memory read for the vtable, and the indirect call to the address of the function
• a function pointer has just one indirect call to the function

This because the virtual function requires to lookup the address of the function it is going to call while the function pointer already knows it (since it's stored in itself).

I would add that, since you are working with C++, virtual methods should be the way to go.