Jump to content
  • Advertisement

Archived

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

genne

optimization of virtual functions

This topic is 5488 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

Hi! Do you think it''s worth using virtual functions? They seem to be slower to call then nonvirtual functions, but also sometimes necessary in order to get a nice structure of your code. For an example:
class Renderer {
public:
    virtual void drawTriangle( const Triangle &t ) = 0;
    // ...

};

class GLRenderer : public Renderer {
public:
    void drawTriangle( const Triangle &t ) {...}
    // ...

};

class Renderable {
public:
    virtual void render( Renderer *r ) = 0;
};

class Some3dObject : public Renderable {
public:
    void render( Renderer *r ) {...}
};

void main() {
    Renderer *r = new GLRenderer();
    Some3dObject o;
    o.render( r );
}
If you call o.render( r ) in every frame, you would loose a lot of speed, wouldn''t you? If you instead skipped all base classes and virtual functions, your code would run faster, but it would also get more ugly. So, how would you solve this?

Share this post


Link to post
Share on other sites
Advertisement
It''s usually a lot better to make an interface to represent an entire strip, fan, or list of triangles. Both GL and D3D are good at drawing a whole bunch of polygons all at once.

I''m hip because I say "M$" instead of "MS".

Share this post


Link to post
Share on other sites
Virtual functions constitute one extra pointer dereference per call. That doesn''t need to be optimized.

Share this post


Link to post
Share on other sites
So the speed loss calling virtual functions should be insignificant? Well, think i could live with one extra pointer dereference per call if it''s giving me the possibility to make the structure of the code nicer. Thx!

Share this post


Link to post
Share on other sites
DirectX uses virtual functions for everything, and that isn''t exactly considered slow, and consider the alternative:

if(opengl)
draw_gl_triangles()
if(dx)
draw_dx_triangles()
...

--------------------------------

"I''m a half time coder, full time Britney Spears addict"
Targhan

Share this post


Link to post
Share on other sites
The speed lose is because your program needs to do a runtime type check whenever you use a virtual function.

So everytime you call a virtual function, your program has to figure out which function to call using this runtime type check.

The quickest way to solve this would be using function pointers. Is the speed lose due to virtual function calls important to you? That depends on your speed vs code complexity tradeoff. Maybe for your case it doesn''t matter. Maybe it does. It depends on the situation

Share this post


Link to post
Share on other sites
well virtual functions are not as expensive as it sounds...for most compilers it shouldnt take no more then 3 memory fetches: one for getting the adress of the vtable, one for getting the adress of the function in the table, and one to fetch the objects offset in the enclosing object.

so if you have a function like
int buffer::operator[](int n) {return innerbufferdata[n];}
making the function virtual will effectively double its ececution time (assuming all memory fetches take the same time), so for example if this is a pixelbuffer that gets accessed thousands of times each frame it is bad to have the function virtual. but in your case, where the drawTriangle etc. functions will themselves probably do hundreds or thousands of operations the virtual function call overhead can be neglected, so there''s nothing wrong with your design



Share this post


Link to post
Share on other sites
Well, in my case, the speed does matters, but i still want the code to be well structured. I''m coding a 3d engine, and every extra frame per second would be appreciated. Though, i''m not sure i would like to sacrifice my "nice looking code" if it only gave me one or two extra frames per second. Perhaps should follow your advice using function pointers instead, might be a possible option!

Share this post


Link to post
Share on other sites
quote:
Original post by Burning_Ice
so if you have a function like
int buffer::operator[](int n) {return innerbufferdata[n];}
making the function virtual will effectively double its ececution time (assuming all memory fetches take the same time), so for example if this is a pixelbuffer that gets accessed thousands of times each frame it is bad to have the function virtual. but in your case, where the drawTriangle etc. functions will themselves probably do hundreds or thousands of operations the virtual function call overhead can be neglected, so there''s nothing wrong with your design


Uhm, that''s actually one of the virtual functions i''m using It only retrieves an element in a private array. I''m using virtual function almost everywhere in my code!

Share this post


Link to post
Share on other sites
well in your case it probably wouldnt give you an extra frame per second, but perhaps an extra frame every couple of minutes, accordingly to how many triangles you render per sec

also, your part
Some3dObject o;
o.render( r );
won't probably have any overhead at all because the static type is known, so your compiler can drop the vtable lookup altogether, since thats only neccessary when calling trough a base-pointer to a child-object (Base* p = new child; ... )


Edit: just read your last post: ok, then it is expensive, but really only if you call it many thousand times each frame





[edited by - Burning_Ice on July 6, 2003 11:37:35 AM]

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!