Static linking vs dynamic linking?

Question

Are there any compelling performance reasons to choose static linking over dynamic linking or vice versa in certain situations? I've heard or read the following, but I don't know enough on the subject to vouch for its veracity. 1) The difference in runtime performance between static linking and dynamic linking is usually negligible. 2) (1) is not true if using a profiling compiler that uses profile data to optimize program hotpaths because with static linking, the compiler can optimize both your code and the library code. With dynamic linking only your code can be optimized. If most of the time is spent running library code, this can make a big difference. Otherwise, (1) still applies.

Answer 1

Hello!

You've asked an interesting question! The answer(s) to this are varied, dependent on a variety of issues, and potentially complex. However, I can perhaps help with a discussion.

A library is a collection of routines (functions) of general use; we typically build libraries to provide functions for use by many programs (although it's not unusual to break a program into libraries, e.g. to separate the program into more manageable parts). Basically, libraries are a binary mechanism of code sharing (reuse).

The answers you found are, generally, correct. (1) The [unoptimized] performance difference is usually negligible, as long as the number of calls from your program into the library is small and infrequent. (Calls into a dynamic library are, necessarily more complicated than a [single], simple function call.) (2) Compile- or link-time optimization, which can do whole program analysis and optimization (with or without profile information), *including* the library code, makes for a powerful combination. Not only are you avoiding the overhead of calling into a dynamic library, but the library code, itself, can be optimized for the way your program uses it.

Static linking is a way of sharing/reusing code at link-time. When a library is linked statically to your program, the functions in the library needed by your program *become* part of the program's executable; their code is copied into your program. They add to the size of the program (and it's load time), add to the link time of the program, add to the complexity of the linkages, and add to the possibility of linkage conflicts. (My code calls my function foo() and the library's function bar(), but the library's function bar() calls the library's function foo(). So, foo() is multiply defined.) However, static linking provides for [more] opportunities for compile- and link-time optimization, across the whole program. Static linking also means that your program will always have the specific version of library code against which you linked.

On the other hand, dynamic linking is a way of sharing code at run-time. When a library is linked dynamically to your program, the functions in the library needed by your program are not copied into you program. Instead, the operating system has a copy of the library in memory for use by any (and all) programs, currently executing, that need any of the library's functions. You program is smaller (because it doesn't contain the library code), loads faster, but can execute more slowly because each initial* call into the library has more overhead than a simple call instruction. (* Sometimes, the operating system can reduce the overhead of a call, once it has been made the first time.) This benefits the operating system, by reducing the amount of physical memory needed to support a particular set of executing programs. Dynamic linking can be complicated by the need to keep, and administer, multiple versions of a library's code.

So, not a short answer. Some operating systems don't support dynamic linking, but they tend to be rare. Having the option means that you have choices. Generally, the decision boils down to performance demands, and ease of use/support.