DLL performance
Author
I had heard that there is a performance penalty when i'm using dynamic linked libraries(DLL)....
I'm designing a system(for a game) with a bounce of DLLS and I was wondering if a static libray is a better chooise? if the penalty of DLLs is going to affect the performance?
hmm i know that you can't say something like: "3 dlls will drop your framerate with 40 fps"...but i wan't to know a little more about this
/ thanks
As far as I know, the only overhead that can possibly occur through use of DLLs is the following. Firstly, when you load it, overhead will be incurred due to the fact that Windows has to map it's code into the processes address space, and do some other stuff. Secondly, there will the overhead of having to call the DLL's exported functions through a function pointer instead of calling them directly. This is of course assuming that you are speaking of run-time linking, that is, loading your DLL manually through LoadLibrary(...). If you are using compile time, or static linking, then neither of those should be a problem.
Keep in mind that I may in fact be incorrect in some of the details [smile] Hope this helps!
Keep in mind that I may in fact be incorrect in some of the details [smile] Hope this helps!
There is a startup penalty, but the runtime performance should not be different than using a statically linked library.
At least, if you discount things like inlining. The only way I can think using a DLL can make things slower is by preventing the compiler doing optimisations it might otherwise do.
Even if there is a performance hit, it should be pretty small - try profiling it yourself.
If your other reasons for using a DLL are valid, don't change because of some perceived tiny performance issue.
Mark
At least, if you discount things like inlining. The only way I can think using a DLL can make things slower is by preventing the compiler doing optimisations it might otherwise do.
Even if there is a performance hit, it should be pretty small - try profiling it yourself.
If your other reasons for using a DLL are valid, don't change because of some perceived tiny performance issue.
Mark
Quote:Original post by markr
There is a startup penalty, but the runtime performance should not be different than using a statically linked library.
Well, the functions still have to be called through function pointers, which does add a (small) performance overhead. At least, I can't see how it can be avoided. Then again, I don't know exactly how dll's are actually implemented, so they might have a dozen clever tricks up their sleeves... [wink]
Quote:Original post by TrapNo, it can also heavily affect your compiler's optimization ability if you cross DLL boundaries a lot.
Cost of DLLs:
At worst it is 1 additional pointer dereference per call.
Every time you call a (non-inlined) DLL function the compiler *has* to assume that anything can happen. Whereas with a static library modern compilers can inline across the boundaries, analyze aliasing constraints, apply profiler-guided optimizations, etc..
Additionally the DLL has to preserve all exported functions, and generally their full names too, which can make your application a lot larger.
However, if your project begins to get large, then splitting things up into DLL's is going to dramatically improve your link time. This can be a nice productivy boost when dealing with moderate to large sized projects. Also, you'll usually expose things from DLL's as interfaces (or at least - you should!) and if you follow the good rule of only exporting a single symbol (the CreateMainInterface() function) from the DLL, it forces a lot of encapsulation, which is again a boon if you have more than one developer.
Quote:Original post by notamac
However, if your project begins to get large, then splitting things up into DLL's is going to dramatically improve your link time. This can be a nice productivy boost when dealing with moderate to large sized projects. Also, you'll usually expose things from DLL's as interfaces (or at least - you should!) and if you follow the good rule of only exporting a single symbol (the CreateMainInterface() function) from the DLL, it forces a lot of encapsulation, which is again a boon if you have more than one developer.
Agreed with teh link time comment, but this speed up comes at the cost of startup time on your app. ie if you statically link your app will start faster as the loader doesn't need to load the dll into memory and then match up the exe's imports with the dll's exports.
Cheers
Chris
Quote:Original post by chollida1True, but it's still a lot faster than the full linking procedure especially when optimizing at link time.
Agreed with teh link time comment, but this speed up comes at the cost of startup time on your app. ie if you statically link your app will start faster as the loader doesn't need to load the dll into memory and then match up the exe's imports with the dll's exports.
And instead of having to jump all over the place fixing up single calls, importing a DLL simply consits of fixing a few entries in a separate import table. So there's no need load the whole program.
On Windows, a DLL call actually vectors through a jump table, so there is one extra indirection in the call stream compared to static libraries (this is for hard-linked DLLs, i e you link with the .lib import library at link time).
On Linux, a DLL (.so) call can actually be patched up to go directly to the site, if the loader and linker co-operate to make it so. However, the Linux position-independent-code methodology is fairly cumbersome, and generates lots of poorly performing glue code, so you should attempt not to use -fPIC.
You'll get the best performance characteristic if you have just a few global functions in your DLL, and make those functions return pointers to an abstract base class (interface). Calls through that interface (virtual functions) will be the same efficiency between DLLs as within the application.
On Linux, a DLL (.so) call can actually be patched up to go directly to the site, if the loader and linker co-operate to make it so. However, the Linux position-independent-code methodology is fairly cumbersome, and generates lots of poorly performing glue code, so you should attempt not to use -fPIC.
You'll get the best performance characteristic if you have just a few global functions in your DLL, and make those functions return pointers to an abstract base class (interface). Calls through that interface (virtual functions) will be the same efficiency between DLLs as within the application.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
