Jump to content
  • Advertisement
Sign in to follow this  
Keba

DLL performance

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

Share this post


Link to post
Share on other sites
Advertisement
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!

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Quote:
Original post by Trap
Cost of DLLs:
At worst it is 1 additional pointer dereference per call.
No, it can also heavily affect your compiler's optimization ability if you cross DLL boundaries a lot.
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
Original post by chollida1
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.
True, but it's still a lot faster than the full linking procedure especially when optimizing at link time.
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!