Virtual methods and performance critical code
Author
I'm currently rethinking the render sub-system of my game engine and I want to move all the API(DirectX)-specific stuff into a separate DLL so I can have different renderers vor different APIs or different API versions. My initial though was to have something like an IRenderDevice interface with a bunch of pure virtual functions that any concrete render device would have to implement. However, now I'm concerned that since these render-methods are going to be called a lot, the dynamic-binding overhead might become an issue. So my question is: should I even worry about this or is the overhead too small to matter?
Quote:the dynamic-binding overhead might become an issue
It might, it might not.
But why would you need virtual functions in the first place? When you load a DLL, you simply bind to the functions it provides. Then you provide a wrapper class no top of those, that is implemented once.
The virtual mechanism here is implicitly provided in the form of DLLs by the OS itself, where implementation is determined by the DLL you just loaded.
Author
Thanks for the reply. My plan was to have the DLL return an instance of a device class to the render-subsystem in the engine, so something along the lines of
With your solution, I'd either have to do it all in a procedural fashion or have a lot of DLL functions that effectively invoke methods on a global instance of the device class, right?
class D3DDevice : IRenderDevice { ... };// DLL-FunctionIRenderRevice* CreateDevice(int param){ return new D3DDevice(param);}With your solution, I'd either have to do it all in a procedural fashion or have a lot of DLL functions that effectively invoke methods on a global instance of the device class, right?
Quote:With your solution, I'd either have to do it all in a procedural fashion or have a lot of DLL functions that effectively invoke methods on a global instance of the device class, right?
No virtuals needed, just bind the functions.
Author
Thanks again!
I read the article and I'm still a little confused.
I'm familiar with the concept of binding "normal" DLL functions, but my render-device is actually a class with (non-static) member functions and I need to be able to instantiate that class from the DLL host (the engine). So just exporting a set of functions won't do. I know I could just drop the class alltogether and use just use plain old functions, but I'd really rather not.
If I used static binding, I could just DLL-export my render device class, but I would like to swap renderers based on a value in a config file so that won't work.
I probably just misunderstood you, though. If so, please enlighten me ;-
I read the article and I'm still a little confused.
I'm familiar with the concept of binding "normal" DLL functions, but my render-device is actually a class with (non-static) member functions and I need to be able to instantiate that class from the DLL host (the engine). So just exporting a set of functions won't do. I know I could just drop the class alltogether and use just use plain old functions, but I'd really rather not.
If I used static binding, I could just DLL-export my render device class, but I would like to swap renderers based on a value in a config file so that won't work.
I probably just misunderstood you, though. If so, please enlighten me ;-
Quote:Original post by Antheus
No virtuals needed, just bind the functions.
That solution is good as long as you just need a wrapper class arroud the DLL static methods. If you need your dll to act like a factory that produces instances of a class that implements an interface, isn't the OP's solution (COM-like) better? (and virtual calls are to be used?)
Regarding the original question, all the methods of a IDirect3dDevice9 are already virtual calls and that doesn't seem to be a performance issue. I wouldn't worry too much if I were you.
Maybe you could implement your own class like:
class OpenGLRenderer : public IDirect3DDevice9and keep the original Direct3D renderer for Direct3D-based rendering ? (so that you don't have 2 layers of virtual calls)
Author
Thanks for the reply!
Sounds like a good solution although inheriting an OpenGLRenderer from a Direct3D-device is really weird ;-)
Sounds like a good solution although inheriting an OpenGLRenderer from a Direct3D-device is really weird ;-)
There is also the fact that the solution on that web page uses function pointers which is pretty much how virtual functions are implemented, and they will entail the same overhead: so, bind static functions, and leave virtual functions as they are.
Quote:Original post by ZQJ
There is also the fact that the solution on that web page uses function pointers which is pretty much how virtual functions are implemented, and they will entail the same overhead: so, bind static functions, and leave virtual functions as they are.
Well, yes.
But here's the question. Will you need dynamic binding, or will static do? Better yet, will there be a need to switch renderers during run-time, or will binding it once during start-up do?
Since there are exactly 2 implementations (OpenGL and DX), there is no need for some ultra-elaborate dynamic binding mechanism.
Developing a plug-in system where an arbitrary number of plug-ins exist is different. But here, there will always be a very deterministic number of different implementations.
Find your trade-off: If performance is priority, forget DLLs, use compile-time polymorphism. If flexibility is a priority, use DLLs, and dynamic bindings (virtual functions will be just fine).
Author
Thanks everyone for the great replies! I will do some profiling to see whether the dynamic binding overhead actually amounts to anything I should be worried about.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
