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

This is a discussion on Is virtual calls really slow or it is just bull........? within the C++ Programming forums, part of the General Programming Boards category; Hi all, Is virtual calls really slow or it is just bull........? With slow do I mean "slow" as I ...

  1. #1
    Registered User
    Join Date
    Feb 2009
    Posts
    40

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

    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!

  2. #2
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    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.

  3. #3
    Registered User
    Join Date
    Apr 2006
    Posts
    2,032
    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.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  4. #4
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Registered User
    Join Date
    Apr 2006
    Posts
    2,032
    Quote Originally Posted by CornedBee View Post
    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.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  7. #7
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,304
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  8. #8
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by King Mir View Post
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  9. #9
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by abachler View Post
    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.

  10. #10
    Registered User
    Join Date
    Jun 2005
    Posts
    6,290
    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.
    Right 98% of the time, and don't care about the other 3%.

  11. #11
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    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.

  12. #12
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Sebastiani View Post
    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...

    Quote Originally Posted by grumpy View Post
    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.
    Last edited by abachler; 09-25-2009 at 10:09 PM.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  13. #13
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by abachler View Post
    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!
    Last edited by Sebastiani; 09-25-2009 at 10:19 PM. Reason: repetitious repetition

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,602
    Quote Originally Posted by abachler View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,304
    Quote Originally Posted by abachler View Post
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 26
    Last Post: 07-05-2010, 10:43 AM
  2. Replies: 48
    Last Post: 09-26-2008, 03:45 AM
  3. pure virtual calls in destructor
    By FillYourBrain in forum C++ Programming
    Replies: 2
    Last Post: 08-21-2003, 08:31 AM
  4. C++ XML Class
    By edwardtisdale in forum C++ Programming
    Replies: 0
    Last Post: 12-10-2001, 10:14 PM
  5. Exporting Object Hierarchies from a DLL
    By andy668 in forum C++ Programming
    Replies: 0
    Last Post: 10-20-2001, 01:26 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21