Application linking

[doof205]

Hi, I'm after a bit of help with regards to linking and the pros / cons of static vs dynamic linking.

At present, We have a large application consisting of ~120 libs / dlls and a 20meg .exe file. Now, looking at most of the projects it seems we almost always build and link to dll's rather than to static libs. The linking is very rarely done at run-time though because almost all of it is used in the application so it all loads at startup.

What is getting to me is that this is one application and we seem to have dll's that are exclusively loaded at startup, never on the fly, which is surely the advantage of dlls?

Why aren't we just using libs? We would then presumably end up with a huge 150 meg .exe file which doesn't sound right to me...but why shouldn't we do it like that? It is one application and surely it'd be faster like that rather than loading 80+ of our own dll's on startup?

I hope my terminology is correct here.

I suppose ultimately my question is this. If you load dll's at startup ALL THE TIME, what is dynamic about that? Why not just use libs?

Thanks for any help on this,

Lewis

[OReubens]

it is always smart to leave MFC and the VC runtime as DLL's. Because other programs not created by you could also be using them.
If multiple exe's are having the SAME dll's loaded, then really, they code is shared among the various processes, and this tends to enhance performance.

If you have dll's that are made by yourself, and which are only ever used by 1 exe, and they're always loaded, then that doesn't really offer much benefit. At best it gives you a means to provided patches to a user only by changing a single DLL rather than the whole lot.
At the same time, by having multiple compilands and linkings, you're preventing the compiler/linker from aggressively weeding out any part that isn't being used.

DLL's really only come into their own when multiple different processes are making use of them.
Alternatively DLL's offer a means to speed up initial load and reduce memory consumption by delay loading, or by dynamic loading and unloading. But if you aren't makinguse of that, then it's another reason against using dll's.

[doof205]

Brilliant, thanks so much for the reply. It seems my thinking is correct from what you say. If we're not making use by delay loading and nothing else should be using our dll's (they shouldn't) then perhaps we should move to static libs.

Is there a limit to exe size with this? I tried changing one of our dlls to a lib and the main exe that linked to it grew by <100k but this allowed me to delete a 3 Mb dll...

The exe is around 20 Mb in debug but I think the release exe is more like 9 Mb...

My worry is that if I chose to change lots of dll's to libs, then the exe could get really large 50-100 Mb which would cause issues I'd imagine.

[S_M_A]

The biggest impact when changing from dll's to static libs will probably be the time you have to spend waiting for the code to link. Also, like most of us you probably work at a place where the it-guys can't sleep at night due to their virus paranoia so the mandatory virus scanner is probably set to scan both on reads and on writes. That means that first are the libs scanned when created, then when the linker reads them and finally the exe is scanned when written. All summing up to making the build process a painful snail-paced experience...

[doof205]

Yes, linking time does seem to be quite high, certainly when linking our exe.

It begs the question of why don't we have two setups? In debug, we could build dll's which are always loaded at startup but allow easy code changes without relinking. in release we could perhaps see a performance increase by moving to static libs when we don't care about relinking times...

I'm curious and might give it a go on a handful of our larger, more heavily used dll's.