Re: When Not to Use virtual Methods for Performance (Was: game development layout question)
- From: Veli-Pekka Tätilä <vtatila@xxxxxxxxxxxxxxxxxxxx>
- To: programmingblind@xxxxxxxxxxxxx
- Date: Sat, 13 Oct 2007 15:32:51 +0300
Tyler,
You said that you don't want to use a common base class pointer and then
have the runtime branch on type implicitly, because it slows down the
game. DO you have any actual data or benchmarks to back this up? I would
be far more worried about the algorithms you actually use to immplement
the game logic slowing it down, or bad GUi code, for that matter.
Rarely hav I seen situations outside of embedded or hard realtime
systems where performance is an excuse not to use OOP if you know the
right design patterns, like Flyweight and Proxy, for managing lots of
small objects. I'd like to quote Bruce Eckel on performance here:
Quote Thinking in C++ 1st Ed ch 15:
typical compiler1 creates a single table (called the VTABLE) for each
class that contains virtual functions. The compiler places the addresses
of the virtual functions for that particular class in the VTABLE. In
each class with virtual functions, it secretly places a pointer, called
the vpointer (abbreviated as VPTR), which points to the VTABLE for that
object. When you make a virtual function call through a base-class
pointer (that is when you make a polymorphic call), the compiler quietly
inserts code to fetch the VPTR and look up the function address in the
VTABLE, thus calling the correct function and causing late binding to
take place. <snip>
You can see from the previous assembly-language output that instead of
one simple CALL to an absolute address, there are two more
sophisticated assembly instructions required to set up the virtual
function call. This requires both code space and execution time. In
addition, inline functions would not be possible, because virtual
functions must have an address to put into the VTABLE. So the virtual
function is an option, and the language defaults to nonvirtual <snip>
When designing your classes, however, you shouldn't be worrying about
efficiency tuning. If you're going to use polymorphism, use virtual
End quote.
Also, mind you, if you branch on your types manually, that's still
branching in the code and adds overhead, too. And while templates for
homogenic containers don't add branching, they do add more object code,
when-ever containers of new types are added, if I've understood thins
correctly. That's why memory conscious embedded environments like
Symbian have an idiom called thin templating, does anyone know how that
works, on a side note?
Just my take on things. Personally I don't even mind the overhead of
langs like Java or Ruby for most apps.
--
With kind regards Veli-Pekka Tätilä (vtatila@xxxxxxxxxxxxxxxxxxxx)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila
"Littlefield, Tyler" wrote:
> note: rtti provides some overhead.
From: Ken Perry
>>Well this can be done several ways. You can use RTTI to check the type or
>>you can have a function in your class that >>returns what it is for example
>>the server I work on has a unit class that has a method GetType that returns
>>four >>different const types. The third method is to make these true virtual
>>classes where each type all have the same >>methods so that it don't matter
>>what type you have you just use the method and it does the right thing.
>><snip>
__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind
Other related posts:
