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

User · Answer

It is pretty simple  really   When you make a change in your source code  do you want to wait 10 minutes for it to build or 20 seconds   Twenty seconds is all I can put up with   Beyond that  I either get out the sword or start thinking about how I can use separate compilation and linking to bring it back into the comfort zone

User · Answer

Dynamic linking requires extra time for the OS to find the dynamic library and load it   With static linking  everything is together and it is a one-shot load into memory   Also  see DLL Hell   This is the scenario where the DLL that the OS loads is not the one that came with your application  or the version that your application expects

User · Answer

On Unix-like systems  dynamic linking can make life difficult for  root  to use an application with the shared libraries installed in out-of-the-way locations   This is because the dynamic linker generally won t pay attention to LD LIBRARY PATH or its equivalent for processes with root privileges   Sometimes  then  static linking saves the day   Alternatively  the installation process has to locate the libraries  but that can make it difficult for multiple versions of the software to coexist on the machine

User · Answer

I agree with the points dnmckee mentions  plus    Statically linked applications might be easier to deploy  since there are fewer or no additional file dependencies   dll    so  that might cause problems when they re missing or installed in the wrong place

User · Answer

Another consideration is the number of object files  translation units  that you actually consume in a library vs the total number available   If a library is built from many object files  but you only use symbols from a few of them  this might be an argument for favoring static linking  since you only link the objects that you use when you static link  typically  and don t normally carry the unused symbols   If you go with a shared lib  that lib contains all translation units and could be much larger than what you want or need

User · Answer

Dynamic linking is the only practical way to meet some license requirements such as the LGPL

User · Answer

Static linking is a process in compile time when a linked content is copied into the primary binary and becomes a single binary  Cons   compile time is longer output binary is bigger  Dynamic linking is a process in runtime when a linked content is loaded  This technic allows to   upgrade linked binary without recompiling a primary one that increase an ABI stability About  has a single shared copy  Cons   start time is slower linked content should be copied  linker errors are thrown in runtime   iOS Static vs Dynamic framework

User · Answer

1  I ve been on projects where dynamic linking vs static linking was benchmarked and the difference wasn t determined small enough to switch to dynamic linking  I wasn t part of the test  I just know the conclusion   2  Dynamic linking is often associated with PIC  Position Independent Code  code which doesn t need to be modified depending on the address at which it is loaded    Depending on the architecture PIC may bring another slowdown but is needed in order to get benefit of sharing a dynamically linked library between two executable  and even two process of the same executable if the OS use randomization of load address as a security measure    I m not sure that all OS allow to separate the two concepts  but Solaris and Linux do and ISTR that HP-UX does as well   3  I ve been on other projects which used dynamic linking for the  easy patch  feature   But this  easy patch  makes the distribution of small fix a little easier and of complicated one a versioning nightmare  We often ended up by having to push everything plus having to track problems at customer site because the wrong version was token   My conclusion is that I d used static linking excepted    for things like plugins which depend on dynamic linking when sharing is important  big libraries used by multiple processes at the same time like C C   runtime  GUI libraries      which often are managed independently and for which the ABI is strictly defined    If one want to use the  easy patch   I d argue that the libraries have to be managed like the big libraries above  they must be nearly independent with a defined ABI that must not to be changed by fixes

User · Answer

static linking gives you only a single exe  inorder to make a change you need to recompile your whole program  Whereas in dynamic linking you need to make change only to the dll and when you run your exe  the changes would be picked up at runtime Its easier to provide updates and bug fixes by dynamic linking  eg  windows

User · Answer

One reason to do a statically linked build is to verify that you have full closure for the executable  i e  that all symbol references are resolved correctly   As a part of a large system that was being built and tested using continuous integration  the nightly regression tests were run using a statically linked version of the executables  Occasionally  we would see that a symbol would not resolve and the static link would fail even though the dynamically linked executable would link successfully   This was usually occurring when symbols that were deep seated within the shared libs had a misspelt name and so would not statically link  The dynamic linker does not completely resolve all symbols  irrespective of using depth-first or breadth-first evaluation  so you can finish up with a dynamically linked executable that does not have full closure

User · Answer

Static linking includes the files that the program needs in a single executable file   Dynamic linking is what you would consider the usual  it makes an executable that still requires DLLs and such to be in the same directory  or the DLLs could be in the system folder     DLL   dynamic link library   Dynamically linked executables are compiled faster and aren t as resource-heavy

User · Answer

There are a vast and increasing number of systems where an extreme level of static linking can have an enormous positive impact on applications and system performance   I refer to what are often called  embedded systems   many of which are now increasingly using general-purpose operating systems  and these systems are used for everything imaginable   An extremely common example are devices using GNU Linux systems using Busybox   I ve taken this to the extreme with NetBSD by building a bootable i386  32-bit  system image that includes both a kernel and its root filesystem  the latter which contains a single static-linked  by crunchgen  binary with hard-links to all programs that itself contains all  well at last count 274  of the standard full-feature system programs  most except the toolchain   and it is less than 20 megabytes in size  and probably runs very comfortably in a system with only 64MB of memory  even with the root filesystem uncompressed and entirely in RAM   though I ve been unable to find one so small to test it on    It has been mentioned in earlier posts that the start-up time of a static-linked binaries is faster  and it can be a lot faster   but that is only part of the picture  especially when all object code is linked into the same file  and even more especially when the operating system supports demand paging of code direct from the executable file   In this ideal scenario the startup time of programs is literally negligible since almost all pages of code will already be in memory and be in use by the shell  and and init any other background processes that might be running   even if the requested program has not ever been run since boot since perhaps only one page of memory need be loaded to fulfill the runtime requirements of the program   However that s still not the whole story   I also usually build and use the NetBSD operating system installs for my full development systems by static-linking all binaries   Even though this takes a tremendous amount more disk space   6 6GB total for x86 64 with everything  including toolchain and X11 static-linked   especially if one keeps full debug symbol tables available for all programs another  2 5GB   the result still runs faster overall  and for some tasks even uses less memory than a typical dynamic-linked system that purports to share library code pages   Disk is cheap  even fast disk   and memory to cache frequently used disk files is also relatively cheap  but CPU cycles really are not  and paying the ld so startup cost for every process that starts every time it starts will take hours and hours of CPU cycles away from tasks which require starting many processes  especially when the same programs are used over and over  such as compilers on a development system   Static-linked toolchain programs can reduce whole-OS multi-architecture build times for my systems by hours   I have yet to build the toolchain into my single crunchgen ed binary  but I suspect when I do there will be more hours of build time saved because of the win for the CPU cache

User · Answer

Another issue not yet discussed is fixing bugs in the library   With static linking  you not only have to rebuild the library  but will have to relink and redestribute the executable   If the library is just used in one executable  this may not be an issue   But the more executables that need to be relinked and redistributed  the bigger the pain is   With dynamic linking  you just rebuild and redistribute the dynamic library and you are done

User · Answer

Best example for dynamic linking is  when the library is dependent on the used hardware  In ancient times the C math library was decided to be dynamic  so that each platform can use all processor capabilities to optimize it   An even better example might be OpenGL  OpenGl is an API that is implemented differently by AMD and NVidia  And you are not able to use an NVidia implementation on an AMD card  because the hardware is different  You cannot link OpenGL statically into your program  because of that  Dynamic linking is used here to let the API be optimized for all platforms

User · Answer

This discuss in great detail about shared libraries on linux and performance implications

User · Answer

1  is based on the fact that calling a DLL function is always using an extra indirect jump  Today  this is usually negligible  Inside the DLL there is some more overhead on i386 CPU s  because they can t generate position independent code  On amd64  jumps can be relative to the program counter  so this is a huge improvement   2  This is correct  With optimizations guided by profiling you can usually win about 10-15 percent performance  Now that CPU speed has reached its limits it might be worth doing it   I would add   3  the linker can arrange functions in a more cache efficient grouping  so that expensive cache level misses are minimised  It also might especially effect the startup time of applications  based on results i have seen with the Sun C   compiler   And don t forget that with DLLs no dead code elimination can be performed  Depending on the language  the DLL code might not be optimal either  Virtual functions are always virtual because the compiler doesn t know whether a client is overwriting it   For these reasons  in case there is no real need for DLLs  then just use static compilation   EDIT  to answer the comment  by user underscore   Here is a good resource about the position independent code  problem http   eli thegreenplace net 2011 11 03 position-independent-code-pic-in-shared-libraries     As explained x86 does not have them AFAIK for anything else then 15 bit jump ranges and not for unconditional jumps and calls  That s why functions  from generators  having more then 32K have always been a problem and needed embedded trampolines   But on popular x86 OS like Linux you do not need to care if the  so DLL file is not generated with the gcc switch -fpic  which enforces the use of the indirect jump tables   Because if you don t  the code is just fixed like a normal linker would relocate it  But while doing this it makes the code segment non shareable and it would need a full mapping of the code from disk into memory and touching it all before it can be used  emptying most of the caches  hitting TLBs  etc  There was a time when this was considered slow   So you would not have any benefit anymore    I do not recall what OS  Solaris or FreeBSD  gave me problems with my Unix build system because I just wasn t doing this and wondered why it crashed until I applied -fPIC to gcc

User · Answer

Dynamic linking can reduce total resource consumption  if more than one process shares the same library  including the version in  the same   of course    I believe this is the argument that drives it its presence in most environments  Here  resources  includes disk space  RAM  and cache space  Of course  if your dynamic linker is insufficiently flexible there is a risk of DLL hell  Dynamic linking means that bug fixes and upgrades to libraries propagate to improve your product without requiring you to ship anything  Plugins always call for dynamic linking  Static linking  means that you can know the code will run in very limited environments  early in the boot process  or in rescue mode   Static linking can make binaries easier to distribute to diverse user environments  at the cost of sending a larger and more resource hungry program   Static linking may allow slightly faster startup times  but this depends to some degree on both the size and complexity of your program and on the details of the OS s loading strategy      Some edits to include the very relevant suggestions in the comments and in other answers  I d like to note that the way you break on this depends a lot on what environment you plan to run in  Minimal embedded systems may not have enough resources to support dynamic linking  Slightly larger small systems may well support dynamic linking  because their memory is small enough to make the RAM savings from dynamic linking very attractive  Full blown consumer PCs have  as Mark notes  enormous resources  and you can probably let the convenience issues drive your thinking on this matter     To address the performance and efficiency issues  it depends   Classically  dynamic libraries require a some kind of glue layer which often means double dispatch or an extra layer of indirection in function addressing and can cost a little speed  but is function calling time actually a big part of your running time       However  if you are running multiple processes which all call the same library a lot  you can end up saving cache lines  and thus winning on running performance  when using dynamic linking relative to using static linking   Unless modern OS s are smart enough to notice identical segments in statically linked binaries  Seems hard  anyone know    Another issue  loading time  You pay loading costs at some point  When you pay this cost depends on how the OS works as well as what linking you use  Maybe you d rather put off paying it until you know you need it   Note that static-vs-dynamic linking is traditionally not an optimization issue  because they both involve separate compilation down to object files  However  this is not required  a compiler can in principle   compile   static libraries  to a digested AST form initially  and  link  them by adding those ASTs to the ones generated for the main code  thus empowering global optimization  None of the systems I use do this  so I can t comment on how well it works   The way to answer performance questions is always by testing  and use a test environment as much like the deployment environment as possible

[c++] Static linking vs dynamic linking

Examples related to c++

Examples related to c

Examples related to performance

Examples related to static-linking

Examples related to dynamic-linking