Is it better to have lots of DLL dependencies or better to static link as mich as possible?
Thanks
views:
191answers:
6
+7
A:
No, it is not bad practice to ship with lots of DLLs; it is bad practice, though, to put them in %System32%. Actually, it is usually good to use DLLs instead of statically linking; for one thing, you can easily swap out just the DLL that you need to update, rather than having to replace the entire binary, and for another, if your program eventually needs multiple executables that work together, you only pay for one copy of the DLL code (whereas, with static linking, you would end up duplicating the code that was common).
Michael Aaron Safyan
2010-08-02 23:54:51
+1 for the multiple executables.
Matthieu M.
2010-08-03 11:53:33
You only pay for one copy of the DLL on disk; in RAM, it's copied per executable.
Ioan
2010-08-04 17:53:48
It's difficult to ensure you only have one copy of a DLL, if there are other apps using eg Qt.dll unless they put them in system your app isn't going to find them. The best you can usually do is share DLLS across apps from your company
Martin Beckett
2010-08-04 18:05:05
@loan, it is possible for it to be implemented as copy-on-write... I don't know how Windows actually implements it.
Michael Aaron Safyan
2010-08-05 01:26:11
@Martin, but that's the correct behavior. Forcing a single copy of a DLL on a system-wide basis is a great way to invoke DLL hell. There are ways to advertise the existence of the DLL without forcing that copy of the DLL on everyone else and without mucking with the system files.
Michael Aaron Safyan
2010-08-05 01:29:12
A:
Having static link gives your app a large memory footprint, therefore having DLL's is better from that POV i.e. you only load what you need. Nowadays installations are normally done by an installer so it doesn't matter if you have lots of DLL's.
Anders K.
2010-08-03 00:10:36
A:
I don't think it's a bad practice. Look at Office or Adobe or any large-scale application. They end up with lots of DLLs -- because they otherwise would have to pack everything into a 100M+ exe.
Break things into DLL when you don't absolutely need them.
kizzx2
2010-08-03 00:20:54
I don't disagree with you. But I wouldn't necessarily hold up Office or Adobe as an example of good software engineering. Or any application that has been around for as many years and as many versions. There are a lot of things that are just historical accidents that are too expensive to change, or due to the fact that hundreds or thousands of developers are working on the same product.
KeithB
2010-08-03 12:40:52
@KeithB: I don't know. I guess any large scale applications need to be broken down into dynamically loaded components -- otherwise you pay the price of wasted performance if the user doesn't access some of the features. Web apps do this in separate script files; games do this using resource files (games are mostly contents; some games pack everything in one big file but they load it piece-meal, same principal hidden behind an optimization trick); etc.
kizzx2
2010-08-03 13:35:43
@kizzx2 I'm not disagreeing with having multiple DLLs. All I'm saying is that "Office does it, so it must be a good idea" isn't a persuasive argument.
KeithB
2010-08-03 16:43:26
A:
Generally speaking it is not a bad practice. It is better to split the code of a program into separated dynamic libraries, especially if the functions provided are used from more than one executable. That doesn't mean that every program should have its code split in more dynamic libraries; for simple utilities, that is not probably needed.
kiamlaluno
2010-08-03 00:26:14
A:
As mentioned by others, lots of DLLs is not a bad practice. Put some thought into what to put in each one. I like to keep the DLLs as 'tiny-island-ish' as I can. If these will be distributed, I like to have a specific naming convention that reflects the product and/or company name and/or initials of some sort.
Edward Leno
2010-08-03 20:20:28
A:
Just wanted to add another observation from other programs that use many dynamically loaded DLLs. For example, the GIMP and its plug-ins. The way you load your DLLs will affect your client's perceived application speed, if that's a factor among the other very good ones (updates, reuse, etc.). I'm sure there's some overhead for the OS to load a DLL and you might run into process limits (like open file handles). Having very many very small DLLs might not be as desired as "smaller than that" number of "larger than that"-sized DLLs.
Ioan
2010-08-04 18:02:13