Static vs. Dynamic Library Performance

Question

It's a general notion that performance of static libraries is greater than that of dynamic. My question is: does it also depend on once the dll is already loaded in memory? I mean, once the initialization and all has happened, does the function calling and execution take longer in case of dynamic libraries than static libraries?

Answer 1

Disclaimer: I am a Linux-fu grasshopper, so there might be some inaccuracies here and there (or just everywhere). But the general idea should be relatively correct.Sort of. And if it's not, I am sure the good SO people will quickly correct me. :-)

Oh, and the links I provided are Windows-centric. I would appreciate if anyone can provide the proper Linux-centric links.

Short answer: It might. However, even if it does, the performance difference is really negligible.

When you link a static library, the compiler generates the code to do all function calls directly. When the process is created, and that code is executed, the function call is a simple call instruction.

When you use a dynamic library, the cost depends on whether you are using load-time dynamic linking or run-time dynamic linking.

With load-time dynamic linking, the compiler still generates code to call the function directly, as if it's a statically linked. When the process loader loads the DLL, it'll invoke the runtime linker to fix the process memory, so that those calls go directly to the actual function implementations. This has to happen before any call to a function from the loaded library is made. on Windows, it's done by the NT DLL loader, which calls LoadLibrary on the DLL at process initialization time. On Linux, it's done by the runtime linker, ld-linux.so.

With /DELAYLOAD load-time dynamic linking, the process is esentially the same, except the compiler generates code to call small stubs, which will check if the library is loaded, and if not, will call the NT DLL loader. Thus, the DLL will be loaded on demand, and the process loader doesn't have to load it at process initialization time. This results in faster process startup time, but the call performance is still the same. (Note however, that delay load suffers from other drawbacks)

I don't know if there's a corresponding Linux support, but I would be surprised if there isn't.

With run-time dynamic linking, your code maintains the function pointers and decides when to dload the library. On Windows, it has to use LoadLibrary and GetProcAddress, on Linux it's dlopen, dlsym and dlclose. In any case, the implications for the process startup time are the same as for the delay-load load-time dynamic linking; however, the pointer dereferencing on each method call does add a small negligible cost. (Although if you know what you are doing, you could go crazy and fix-up your process memory to avoid the pointer dereferencing. The effort to do this right however is an order of magnitude bigger than the perf benefits you'll get for doing it.)

Answer 2

The machine code itself in a DLL or static library have ofc the same performance. A compiler can though more aggressively optimize an executable with static libraries, especially when link-time code generation is turned on. One can think of removal of unused variables and duplicate code and placement of code close to each other when used together (see PGO).

When code is shared across applications it's better to use DLL's from a system performance point of view, since the overall memory pressure of the system is less (when os is able to map views of memory sections across processes which Windows does).

Answer 3

I think the biggest difference, performance-wise, is that with a static library the compiler can optimize function calls to the library, but in a dynamic one the compiler knows nothing about the behaviour of the function it is calling.