由于动态链接的库必须在运行时解析，静态链接的可执行文件是否比动态链接的可执行文件更快？
【问题讨论】：
标签： performance dll linker static-linking dynamic-linking
静态链接比动态链接产生更大的可执行文件，因为它必须将所有库代码直接编译成可执行文件。好处是不再需要从库中调用函数，从而减少了开销，并且加载时间从稍微加快到明显加快。
动态链接的可执行文件会更小，因为它会在运行时调用共享代码库。这样做有几个好处，但从速度或优化的角度来看，重要的是减少磁盘空间和内存消耗量，以及由于减少总资源消耗而改进的多任务处理（尤其是在 Windows )。
所以这是一个权衡：有理由提出为什么其中任何一个都可能稍微快一点。这将取决于许多不同的事情，例如程序中对速度至关重要的例程在多大程度上依赖于对库函数的调用。但在上述声明中要强调的重要一点是它可能略微更快。 速度差异几乎难以察觉，即使与正常的预期波动也难以区分。
如果您真的在乎，请对其进行基准测试并查看。但我建议这是浪费时间，并且有更有效和更重要的方法可以提高应用程序的速度。在做出“动态链接或静态链接”决定时，考虑到速度以外的因素，从长远来看，你会做得更好。例如，如果您需要使您的应用程序更易于部署，特别是对于不同的用户环境，静态链接可能值得考虑。或者，动态链接可能是更好的选择（特别是如果这些共享库不是您自己的），因为您的应用程序将自动获得对其调用的任何共享库进行升级的好处，而无需动动手指。
编辑：Microsoft 提出您的具体建议prefer dynamic linking over static linking：
不建议转发 静态的 C/C++ 应用程序 链接到 Visual C++ 库。它是 经常错误地认为 将您的程序静态链接到 Visual C++ 库 显着提高性能 的应用程序。然而影响 关于动态加载的性能 Visual C++ 库是微不足道的 在几乎所有情况下。此外， 静态链接不允许 服务应用程序及其 依赖库由 应用程序的作者或 Microsoft。为了 例如，考虑一个应用程序 静态链接到特定的 库，在客户端计算机上运行 使用此库的新版本。 该应用程序仍然使用来自 该库的先前版本， 并且没有从图书馆中受益 改进，例如安全性 增强功能。 C/C++ 的作者 强烈建议申请 考虑服务场景 在决定静态链接到之前 依赖库，并使用动态 尽可能链接。
【讨论】：
这取决于您的磁盘状态以及 DLL 是否可能在其他进程中使用。当您的程序及其 DLL 以前从未加载过时，就会发生冷启动。没有 DLL 的 EXE 具有更快的冷启动，因为只需要找到一个文件。您必须有一个几乎已满的严重碎片磁盘才能没有这种情况。
当 DLL 已经加载到另一个进程中时，它就可以开始发挥作用了。现在 DLL 的代码页被简单地共享，启动开销非常低并且内存使用效率很高。
有点类似的情况是热启动，即 DLL 在文件系统缓存中仍然可用的启动。在缓慢的磁盘上，冷启动和热启动之间的差异可能非常显着。每个人都喜欢 SSD 的原因之一。
【讨论】：
不，我不这么认为。在大多数情况下，每个程序仅在内存中复制一个库会使整个系统的内存减少。假设您有 100 个程序静态使用 libc 库，而 libc 大约为 2-3MB，因此它会增加程序的大小。 但同样在动态中，我们可以共享内容，因此内存中的字节越少，缓存中的字节越多，缓存中的字节越多，速度越快。 虽然它有加载开销，但您的整体系统性能更快。
【讨论】：