Virtual function overhead. How bad is it?
Author
Hi all,
I just wanted to ask some questions about virtual funcitons and polymorphism. How much overhead is it to lookup a function in the vtable when I make a call to a virtual function? I know this is a majorly debated issue when it comes to speed, but how bad is it really? If I have one virtual function call in my main game loop, is it really going to degrade performance that much?
I'm of the opinion that I should use them, but not overuse them. What do you all think?
Thanks,
Dave
I'd agree, in most cases I'd imagine the overhead generated by the vtable should be smaller than the cost of writing a workaround that would likely be less natural.
Quote:Original post by Estraven
How much overhead is it to lookup a function in the vtable when I make a call to a virtual function?
Do you mean conceptually or quantitatively? Conceptually it's the same as getting a value from an array before you make the function call. Quantitatively, I don't know, you might want to measure it yourself.
Quote:Original post by Estraven
I know this is a majorly debated issue when it comes to speed, but how bad is it really?
It depends entirely on the context in which they're being used.
Quote:Original post by Estraven
If I have one virtual function call in my main game loop, is it really going to degrade performance that much?
You can have a thousand virtual function calls in your main loop and you won't notice any speed difference whatsoever (on anything later than a 60 Mhz Pentium).
Quote:Original post by Estraven
I'm of the opinion that I should use them, but not overuse them. What do you all think?
I agree with everything that has been said. I feel that the overhead is really not a problem. Same goes with using .dlls, there's overhead, but look at all of the benefits. It makes it worth it. As for your opinion of not overusing them, that should be applied with anything, so I agree. So in short, it's not bad at all. From my experiences, using VFuncs can even speed up your code.
- Drew
Your apps memory and usage footprint has a significant effect as well - when your app is small, or uses code in a very localized way (like runs a tight AI algorithm for 1000 loops, then a renedering algorithm, etc ... (in a nice chunked way), then the vtables it's using most of the time will always be in cache, and therefore very efficient (just a few clock cycles lost). However, like any cache miss in a performance critical section, when they are not cached, the cost is great. I have often wanted to see how modern compilers place the vtables in the EXE image to see if they attempt to improve cache coherence, or if they just go where they go with no adjustment.
Unless your compiling for a 386 don't bother worrying about it. Seriously people get all uptight about how virtual functions are so slow but I've never had a situation where I could even tell! In my code I use virtual functions all the time. Each entity uses them for their update and render calls (so that can be upto 100 calls each tick), each gui window type uses them, as well as lots of other things. I once hard coded my game to only use a certain type of entity so that there were no virtual function calls and then timed it ... there was no difference that I could detect. I'm sure if I added maybe 1,000 to 1,000,000 entities to my game world then I'd see a difference but it saves me so much time that its definatly worth it. I'm sure I'd speed up my game way more by fixing the physics or the AI code rather than getting rid of virtual functions. How often do you worry about accessing an array item? thats about the same cost (or so I believe) :P
Quote:Original post by EstravenAlways take a good look at who is debating. Most of the people who speak of "optimization" and "speed" write slow code because of their attempts at silly optimizations.
I know this is a majorly debated issue when it comes to speed...
Use them where they make sense.
Another "me too!" post, but here goes:
If the object is predominantly of one particular type, branch prediction in modern (Athlon, P3 and newer) CPUs will actually take care of it to the extent that it's practically free. Even if you often call different objects, you shouldn't have any trouble, any workarounds are going to be more expensive.
~phil
If the object is predominantly of one particular type, branch prediction in modern (Athlon, P3 and newer) CPUs will actually take care of it to the extent that it's practically free. Even if you often call different objects, you shouldn't have any trouble, any workarounds are going to be more expensive.
~phil
Hey,
As stated, the effect is negligable. But do take note that there are situations where silly virtual inheritence just complicates the whole issue - it's sometimes difficult to determine where a virtual function comes from if you're inheriting from many classes which have the same virtual function pointer, and AFAIK most compilers won't give you warnings to ambiguous virtual functions, they just replace the VTable entry with the last constructed object which overloads it.
CJM
As stated, the effect is negligable. But do take note that there are situations where silly virtual inheritence just complicates the whole issue - it's sometimes difficult to determine where a virtual function comes from if you're inheriting from many classes which have the same virtual function pointer, and AFAIK most compilers won't give you warnings to ambiguous virtual functions, they just replace the VTable entry with the last constructed object which overloads it.
CJM
Quote:Original post by JonnyQuestNot to mention, workarounds might actually be more expensive with new CPUs. This goes for pretty much every workaround optimization. Before you start rolling your own, remember that compilers and CPUs will continue to be developed with speeding up the standard method. By avoiding that, you may actually impede optimizations you would have recieved for free.
If the object is predominantly of one particular type, branch prediction in modern (Athlon, P3 and newer) CPUs will actually take care of it to the extent that it's practically free. Even if you often call different objects, you shouldn't have any trouble, any workarounds are going to be more expensive.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
