在某些情况下，选择静态链接而不是动态链接或反之，是否有令人信服的性能原因?我听过或读过以下内容，但我对这个主题了解不够，无法保证其真实性。
1)静态链接和动态链接在运行时性能上的差异通常可以忽略不计。
如果使用使用概要数据优化程序热路径的分析编译器，2)(1)是不正确的，因为使用静态链接，编译器可以优化你的代码和库代码。使用动态链接，只能优化您的代码。如果大部分时间都花在运行库代码上，这可能会有很大的不同。否则，(1)仍然适用。
当前回答
在类unix系统上，动态链接会使“root”很难使用安装在偏僻位置的共享库的应用程序。这是因为对于具有根权限的进程，动态连接器通常不会注意LD_LIBRARY_PATH或其等效内容。有时，静态链接可以解决问题。
另外，安装过程必须确定库的位置，但这可能会使计算机上的多个软件版本难以共存。
其他回答
动态链接需要额外的时间让操作系统找到动态库并加载它。使用静态链接，所有内容都在一起，并且只需要一次性加载到内存中。
另外，参见DLL地狱。在这种情况下，操作系统加载的DLL不是应用程序自带的，也不是应用程序期望的版本。
另一个尚未讨论的问题是修复库中的错误。
使用静态链接，您不仅需要重新构建库，还必须重新链接和重新分发可执行文件。如果库只在一个可执行文件中使用，这可能不是问题。但是，需要重新链接和重新分发的可执行文件越多，痛苦就越大。
使用动态链接，只需重新构建和重新分发动态库，就完成了工作。
静态链接是在编译时将链接的内容复制到主二进制文件中并变成单个二进制文件的过程。
缺点:
编译时间更长 输出二进制更大
动态链接是在运行时加载链接内容的过程。这项技术允许:
升级链接二进制文件而不重新编译主二进制文件，增加ABI稳定性[关于] 是否有单个共享副本
缺点:
开始时间较慢(应复制链接内容) 链接器错误在运行时抛出
[iOS静态vs动态框架]
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.
静态链接只给你一个单一的exe，为了做出改变，你需要重新编译你的整个程序。而在动态链接中，您只需要对dll进行更改，当您运行exe时，这些更改将在运行时被拾取。通过动态链接(例如:windows)更容易提供更新和错误修复。
