I'm working on a game engine in C# and recently I ended up having to convert the engine into a class library because it was too tedious to have to copy the engine and keep all the copies updated whenever I needed to create a new tool/sample/test using it. However, the framerate dropped from 60FPS/ ~16ms per frame to 30FPS/ ~26 ms per frame. So I'm worried, is the overhead from having class libraries that high? Should I go for some other setup? If so what? I'm thinking maybe if I make the engine the executable and the tools be the class libraries, but I'm not sure if that will change anything.
Overhead of separating the game engine into a class library
Profile it before and after. Just moving code into a class library shouldn't do that.
It's possible that when you created the class library, its project settings differ from the original. Double check your class library to make sure it's using the proper debug/release settings and optimization settings you want.
It's possible that when you created the class library, its project settings differ from the original. Double check your class library to make sure it's using the proper debug/release settings and optimization settings you want.
No, there shouldn't be any noticeable overhead. Something must be wrong.
Is your render loop sync'd to vertical retrace? Maybe you went from 60FPS to 59FPS, but your rendering is now "clamped" to 30FPS.
The typical cost of using a shared library is just an indirect subroutine call instead of a direct one because, well, it IS a dynamic library so the calls must not be set in stone. And even then, I think managed .NET bytecode code might not even have to pay that cost because you can't ever unload an assembly from an AppDomain, so the JIT compiler should be allowed produce direct subroutine calls to non-virtual library functions. There's also the time to load the library in the process (obviously) but you pay that price only once.
It's probably something you did while moving the engine to its class library.
Did you add console or debug printouts while porting to test your library? Stdin and stdout are not very fast I/O.
Did you introduce a memory leak while porting? The garbage collector will kill your frame rate if it gets too excited.
If for whatever reason you load your library in a different AppDomain than your game, this is a no-no.
If you had to decouple code between engine and game, what did you use? Interfaces? Delegates? Events?
Other than that, I don't really see what could go wrong if you just moved engine classes to their own class library. You sure you didn't try to "improve" some code during the porting process? I'd say 80% of the time porting problems are when the programmer who ported the code didn't just port the code. 
It's better to just note what you find ugly and come back to it once the port is done. If you use // TODO to annotate, Visual Studio will even keep track of them for you in the task window.
If you can't find the problem on your own, I'd also recommend to just get a profiler to see where the bottleneck is.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
