Is virtual calls really slow or it is just bull........?

**idleman** · 09-25-2009

Hi all,

Is virtual calls really slow or it is just bull........? With slow do I mean "slow" as I should notice it, not just some extra nanoseconds or so, that do I not really call slow. Of course should it probably have a negative impact on a critical section/application, but now do I mean a normal program that is normally not limited to CPU power but more network, disk IO and such resources. I wonder because I just have started to use virtual methods in many classes, and is thinking of I should use it together with multiple inheritance. My application should then be much easier to maintain and extend.

Thanks in advance!

**Sebastiani** · 09-25-2009

Short answer: Total bull.

Long answer: It depends. Since the standard doesn't dictate the particular format used or techniques employed, compiler vendor are free to implement it however they wish. That said, most implementations do so quite efficiently, so in general it really shouldn't be an issue.

**King Mir** · 09-25-2009

It basically has the cost of two extra memory accesses, which isn't a high cost at all. One if the implementation chooses to store the v-table with the object.

**abachler** · 09-25-2009

I woudln't use it in the inner loop of a games physics engine, but its fine for things that don't get executed very often. I personally never use the virtual keyword, 99.99999% of problems can be solved in a trivial manner using other methods.

**CornedBee** · 09-25-2009

A normal call is:

call direct

A virtual call is:

load vtable pointer
load function pointer
call indirect

The biggest problem is that it can really mess up the branch predictor.

**King Mir** · 09-25-2009

Originally Posted by CornedBee

The biggest problem is that it can really mess up the branch predictor.

That and the extra memory accesses can cause a cache miss or a page fault.

**iMalc** · 09-25-2009

It should be pretty tiny impact compared to the code inside the function, and that's if it's not already translated to a direct call by the optimiser where possible.

**abachler** · 09-25-2009

Originally Posted by King Mir

That and the extra memory accesses can cause a cache miss or a page fault.

Highly unlikely it will cause a page fault. it will most certainly cause cache misses, but only the first time it is called, after that the data will be in the cache. what slows it down is the extra memory accesses, which is why its very bad to use as part of an inner loop. Inner loops are inherently CPU bound if designed properly. Any extra work will slow the system down.

Now with THAT said, its probable that in most cases you will never notice the difference.

**Sebastiani** · 09-25-2009

Originally Posted by abachler

Highly unlikely it will cause a page fault. it will most certainly cause cache misses, but only the first time it is called, after that the data will be in the cache. what slows it down is the extra memory accesses, which is why its very bad to use as part of an inner loop. Inner loops are inherently CPU bound if designed properly. Any extra work will slow the system down.

Now with THAT said, its probable that in most cases you will never notice the difference.

That is true. If you're, say, processing an image and trying to squeeze every last drop of performance out of it, avoiding virtual dispatches can make a noticeable difference. But of course, in that situation even a single unnecessary multiply is going to be a concern, and moreover, writing clear, concise code is quite simply a luxury you can't afford! Desperate times call for desperate measures.

**grumpy** · 09-25-2009

Assuming virtual function support involves a virtual function table, the same class of overheads occur in C with using a "pointer to function" to call a function - apart from concerns of loading argument lists, it's necessary to retrieve the function pointer, load it, and then do an indirect call.

An alternative mechanism (eg switch on the type, and call the corresponding function) has the overhead of selecting which function to call. Few compilers do this.

Either way, as others have said, the overhead is usually insignificant outside of tight inner CPU-bound loops. There is a measurable overhead, as there is with anything, but significance depends on the context in which it is done.

**Sebastiani** · 09-25-2009

I just wanted to point out that C++ provides another useful (tho' often unused) facility for virtual dispatch - The curiously recurring template pattern:

Code:

template < typename Derived >
class behavior
{
    public:
    
    template < typename Type >
    inline void act( Type const& data )
    {
        static_cast< Derived* >( this )->act( data );
    }
};

class foo : public behavior< foo >
{
    public:

    inline void act( int data )
    {
        cout << data << endl;
    }
};

class bar : public behavior< bar >
{
    public:

    inline void act( double data )
    {
        cout << data << endl;
    }
};

The most interesting points are:
1) All of the function calls would be expanded inline by a decent compiler (depending on the internal code, naturally, but certainly the base class function would be in all cases).
2) The base class function can be templated, for flexibility. If so, the derived classes can even define several functions with the same name, making it a much more powerful paradigm altogether, compared with 'ordinary' virtual functions.

**abachler** · 09-25-2009

Originally Posted by Sebastiani

That is true. If you're, say, processing an image and trying to squeeze every last drop of performance out of it, avoiding virtual dispatches can make a noticeable difference. But of course, in that situation even a single unnecessary multiply is going to be a concern, and moreover, writing clear, concise code is quite simply a luxury you can't afford! Desperate times call for desperate measures.

Are you actually claiming that making a call virtual clarifies the code? I'm laughing so hard I think I pooped a little...

Originally Posted by grumpy

Assuming virtual function support involves a virtual function table, the same class of overheads occur in C with using a "pointer to function" to call a function.

Utter horse manure. A pointer to a function has no run-time overhead, that's the whole point of using them.

Code:

call foo

becomes

Code:

call [foo]

which involves only a single extra memory lookup.

virtual adds more than a single lookup iirc.

**Sebastiani** · 09-25-2009

Originally Posted by abachler

Are you actually claiming that making a call virtual clarifies the code?

Well it's certainly more concise than the 15 lines of inline assembly and highly-optimized lookup tables you hand-coded to replace it!

**Elysia** · 09-26-2009

Originally Posted by abachler

Utter horse manure. A pointer to a function has no run-time overhead, that's the whole point of using them.

Yeah it does. If you do not think so, I would like to see some sort of proof of otherwise.

**iMalc** · 09-26-2009

Originally Posted by abachler

Utter horse manure. A pointer to a function has no run-time overhead, that's the whole point of using them.

Choose your words carefully...
Remember that run-time overhead comes in at least two flavours, speed overhead and memory overhead.
If you were coding your own function pointers in C then if you stored more than one function ptr per class you'd have a higher memory overhead than the way C++ compilers usually do it, and if you only stored a pointer to the list of function pointers, well then you've got it exactly the way C++ compilers do it. But then the C++ compiler still wins because it can optimise it out in some cases whereas the C code most likely cant since you've effectively told it how to do virtual functions rather than simply saying that you want a certain behaviour. The only way you'll get an overhead that isn't higher in either memory usage or speed is if you only have a single function pointer. Probably no reason a C++ compiler couldn't sometimes make a similar optimisation for such a case though.

No point us dwelling on the low-level details though. When used in properly designed code, their impact is negligible.

Thread: Is virtual calls really slow or it is just bull........?

Thread Tools

Search Thread

Display

Is virtual calls really slow or it is just bull........?

Similar Threads

How to sort a simple linked list using swap-sort method

Abnormal Program Termination when executed from C:/Program Files

pure virtual calls in destructor

C++ XML Class

Exporting Object Hierarchies from a DLL