2

I have a function that needs to call a virtual method many times in a loop and was hoping there would be a way to avoid the overhead of a vtable lookup every time. I thought maybe obtaining a pointer to the method would be a good way round this. The code below shows what I'm trying to do, the problem being that the address of a method in Derived cannot be assigned to a Base member function pointer.

class Base
{
    public:

    typedef float ( Base::*MFP )( float const & x ) const;

    virtual MFP getMFP( void ) const = 0;

    virtual float function( float const & x ) const = 0;
};

class Derived : public Base
{
    public:

    virtual MFP getMFP( void ) const
    {
        return &Derived::function;
    }

    virtual float function( float const & x ) const
    {
        return x * x;
    }
};

class Other
{
    public:

    float calculate( float const & x, Base * pBase ) const
    {
        Base::MFP function = pBase->getMFP();
        return ( ( *pBase ).*( function ) )( x );
    }
};

Is there a way to do what I'm trying to do here?


EDIT:

For anyone who's still interested I ran a timed test of my code. Turns out dynamic dispatch only slowed down my calculation method by 0.004%, so pretty much nothing. Compiled using MSVC 2010 with full optimisation.

PeddleSpam
  • 418
  • 3
  • 10
  • You need to have a vtable lookup to ensure you are calling the right function. That is the whole point of having a virtual function... – Jerome Jun 26 '12 at 19:57
  • 2
    Have you profiled this code? Is it unambiguously the vtable lookup that's giving you performance issues? – Alex Wilson Jun 26 '12 at 19:59
  • Your compiler can do that itself in some cases (only doing the lookup once). Did you verify the (optimized) assembly it outputs? – Mat Jun 26 '12 at 20:01
  • I haven't profiled it yet, the overhead probably won't be that significant. It just seems like an obvious optimisation, since the type of the object won't change why perform a vtable lookup ten or twenty times when once will suffice? – PeddleSpam Jun 26 '12 at 20:07
  • possible duplicate of [How to obtain a pointer out of a C++ vtable?](http://stackoverflow.com/questions/5099967/how-to-obtain-a-pointer-out-of-a-c-vtable) – Eran Jun 26 '12 at 20:23

4 Answers4

4

Your idea is based on an incorrect assumption that creating such pointer will take VMT access out of the loop (i.e. perform it once instead of performing it repeatedly in the loop).

In C++ language calls through pointers of "pointer-to-member function" type (which happen to be bound to a virtual member function) are always resolved at the moment of the call, not at the moment of initialization. This means that even if you create such a pointer, it will not optimize anything at all. Each call in the loop will still perform a full-blown access to VMT, just like it was without any pointers.

In C++ there's no way to force such a pointer to point to a specific version of a virtual function at the moment of initialization. C++ language simply has no such feature.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • I hadn't considered that, I did just assume that a member function pointer, once initialised, would contain the address of the actual method. Thanks for the in-depth answer +1 – PeddleSpam Jun 26 '12 at 20:38
2

Don't do it. The processor has deep pipelines, and the compiler is almost certainly already caching the function pointer. You can do this with some effort. But I guarantee that on any compiler less than 10 years old this will make no difference.

Rafael Baptista
  • 11,181
  • 5
  • 39
  • 59
  • I was hoping the compiler would be able to do that, especially if I pass by reference or declare the pointer constant. – PeddleSpam Jun 26 '12 at 20:25
0

I would avoid premature optimization until it becomes a problem; and then, and only then, after you have profiled your code do you make changes. Shoot for maintainability and extendability first, and if you still are having performance issues look to refactor. In this example, the look-ups have very little overhead.

I'd rather look at code that is readable than code that has a 5% performance increase but takes me all day to figure out what it's doing.

keelerjr12
  • 1,693
  • 2
  • 19
  • 35
0

The easiest way would be a cast, if you know for certain that the object in the for loop is a Derived.

void foo(float);
Base* pObject;
//...
//If you know with certainty that the object is a Derived
Derived& der = *static_cast<Derived*>(object)
for(float x : floatContainer)
{
     foo(der.function(x));
}

This means you'll only invoke Derived's vtable, which is potentially faster depending on how many classes derive from Derived. If all you can guarantee is that the class is a Base, then what you've written in the question above is essentially a vtable, except much slower than anything the compiler would produce. You may have heard that vtables are slow, and maybe that's true compared to raw C pointers and functions, but I can all but completely guarantee that it'll be fast enough for what you need.

Lucretiel
  • 3,145
  • 1
  • 24
  • 52
  • This would defeat the object of having a polymorphic type. If I knew the method would only use the `Derived` type I would pass a reference to a `Derived` object and do away with the pointer to base. – PeddleSpam Jun 26 '12 at 20:43
  • I don't see how it can optimize anything. In a typical implementation V-table access, once it's there, has the same performance penalty regardless of inheritance structure. There might be some performance differences in multiple-inheritance configurations, but in this example there won't be any. – AnT stands with Russia Jun 27 '12 at 05:19