Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

hewhay

C++ Abstract class performance penalty

This topic is 5474 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I will try to make a c++ class for creating windows. To manage the window event i''m planning to use an interface much like
 
class WindowEventHandler
{
    virtual void OnDraw () = 0;
    virtual void OnSize () = 0;
    ...
}

The window class will contain a pointer to a WindowEventHandler, and the registered window callback will:
...
case WM_PAINT:
    wnd->handler->OnDraw ();
...

 
The GameEngine class is going to implement this interface can somebody tell me if this will cause any noticiable performance penalty?

Share this post


Link to post
Share on other sites
Advertisement
if you want to be cool, make an interface using the windows construct as follows:




DECLARE_INTERFACE(IWindowEventHandler) {
virtual void OnDraw() = 0;
virtual void OnSize() = 0;
// ...
};


class MYWINDOWEVENTHANDLER : public IWindowEventHandler {
};




If I am not mistaken, this formal INTERFACE facility directly maps calls to their rightfull functions, without the lookup tables. it also looks cool in the class viewer (its a little bar with a circle attached to it)

Your event handler then is the same where wnd is:
"IWindowEventHandler * wnd";



//...
//...
case WM_PAINT:
wnd->handler->OnDraw ();
...


the rest is the same.

Share this post


Link to post
Share on other sites
A quick test suggests that a virtual function call on my computer takes an average of 13.3 nanoseconds. In a program that only does anything in response to user input, you''d need to call about a million virtual functions before you''re even close to the user noticing.

Share this post


Link to post
Share on other sites
That last arguement is void though because when your whole application is doing function look up''s, the user *WILL NOTICE*. However, yea virtual functions rule.

Share this post


Link to post
Share on other sites
thks,
virtual functions are slow because they have to check the vtable? right?

Pointers to members store the address of a function so if i do:



class Interface
{
void function ();
}

class Concrete : Interface
{
void function () { /* wathever */ }
}

void Interface::*ptr ();

...

Concrete* clsPtr = new Concrete ;

ptr = clsPtr::function; // the vtable is checked here

clsPtr->*ptr (); // is it checked here also?


...

can i do that on the first place?



[edited by - hewhay on September 24, 2003 9:16:45 PM]

Share this post


Link to post
Share on other sites
Listen to Beer Hunter. If you don''t use virtual functions, you will have to implement the same mechanism yourself. And chances are that the compiler writers write more efficient code than you do.

Your code won''t work because clsPtr::function isn''t valid, because clsPtr is not a class.

Most optimizations that you can think of about v-functions will probably already be done by a smart compiler anyway.

Cédric

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Newbies choose the worst algorithms and make the craziest *non-useful* micro-optimizations. "Oooohh function calls are so slow, I must inline everything by hand".. "And emulate virtual functions with switches!".. "See I wrote this 10000 line switch-case and gained -10% in speed. Ain''t that cool?"..

Compiler is smarter than you in micro-optimization.

(had too little sleep so I''m grumpy. Ignore)

Share this post


Link to post
Share on other sites
virtual function involes only a lookup in a table and then a call.
so it only about 2 more instruction calls form a reg function call.
Which is basicly nothing compare to what you want to do.
Plus what you want to do is more readable and therefore could be more maintainable.

Lord Bart

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!