动态链接的最佳示例是库依赖于所使用的硬件。在古代，C数学库是动态的，这样每个平台都可以使用所有的处理器功能来优化它。

一个更好的例子可能是OpenGL。OpenGl是一个由AMD和NVidia实现的不同的API。你不能在AMD卡上使用NVidia实现，因为硬件是不同的。因此，你不能静态地将OpenGL链接到你的程序中。这里使用了动态链接，以便为所有平台优化API。

1)基于这样一个事实，即调用DLL函数总是使用额外的间接跳转。如今，这通常可以忽略不计。在DLL内部，i386 CPU上有一些更多的开销，因为它们不能生成与位置无关的代码。在amd64上，跳转可以相对于程序计数器，因此这是一个巨大的改进。

2)这是正确的。通过分析引导的优化，您通常可以获得大约10- 15%的性能。既然CPU速度已经达到极限，那么这样做可能是值得的。

我想补充的是:(3)链接器可以将函数安排在一个更有效的缓存分组中，从而将昂贵的缓存级别的失败最小化。它还可能特别影响应用程序的启动时间(基于我在Sun c++编译器中看到的结果)

不要忘记，使用dll不能执行死代码消除。根据语言的不同，DLL代码也可能不是最佳的。虚函数总是虚函数，因为编译器不知道客户端是否正在覆盖它。

由于这些原因，如果不需要dll，那么就使用静态编译。

编辑(通过用户下划线回答注释)

这里有一个关于职位独立代码问题的很好的资源http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/

正如所解释的，x86除了15位跳转范围之外没有其他的AFAIK，也没有无条件跳转和调用。这就是为什么函数(来自生成器)超过32K一直是一个问题，需要嵌入蹦床。

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.

这样你就没有任何收益了。

我不记得什么操作系统(Solaris或FreeBSD)给我的Unix构建系统的问题，因为我只是没有这样做，不知道为什么它崩溃，直到我应用-fPIC到gcc。

我同意dnmckee提到的观点，另外:

静态链接的应用程序可能更容易部署，因为很少或没有额外的文件依赖项(.dll / .so)，当它们丢失或安装在错误的位置时，可能会导致问题。

静态链接只给你一个单一的exe，为了做出改变，你需要重新编译你的整个程序。而在动态链接中，您只需要对dll进行更改，当您运行exe时，这些更改将在运行时被拾取。通过动态链接(例如:windows)更容易提供更新和错误修复。

动态链接需要额外的时间让操作系统找到动态库并加载它。使用静态链接，所有内容都在一起，并且只需要一次性加载到内存中。

另外，参见DLL地狱。在这种情况下，操作系统加载的DLL不是应用程序自带的，也不是应用程序期望的版本。

执行静态链接构建的一个原因是验证可执行文件是否完全关闭，即所有符号引用都正确解析。

作为使用持续集成构建和测试的大型系统的一部分，夜间回归测试使用可执行文件的静态链接版本运行。偶尔，我们会看到一个符号无法解析，静态链接会失败，即使动态链接的可执行文件可以成功链接。

这种情况通常发生在共享库中位置较深的符号有拼写错误的名称，因此不能进行静态链接时。无论使用深度优先还是宽度优先求值，动态链接器都不能完全解析所有符号，因此您可以完成一个没有完全闭包的动态链接可执行文件。