静态链接的可执行文件是否比动态链接的可执行文件更快?

时间:2011-01-12 10:49:01

标签: performance dll linker static-linking dynamic-linking

由于必须在运行时解析动态链接库,静态链接的可执行文件是否比动态链接的可执行文件更快?

2 个答案:

答案 0 :(得分:15)

静态链接产生比动态链接更大的可执行文件,因为它必须将所有库代码直接编译到可执行文件中。这样做的好处是可以减少开销,从而不再需要从库中调用函数,以及从某种程度到明显更快的加载时间。

动态链接的可执行文件会更小,因为它会在运行时将调用放到共享代码库中。这有几个好处,但从速度或优化的角度来看,重要的是减少磁盘空间和内存消耗,并改善多任务处理,因为资源消耗减少(特别是在Windows中) )。

所以这是一个权衡:有争论的原因是为什么其中任何一个可能会略微加快。它取决于许多不同的东西,例如程序中速度关键例程在多大程度上依赖于对函数库的调用。但在上述陈述中要强调的重点是它可能略微更快。 速度差异几乎不易察觉 ,甚至难以区分正常的预期波动。

如果你真的在乎,请对它进行基准测试。但我建议这是浪费时间,并且有更有效和更重要的方法来提高应用程序的速度。从长远来看,考虑到“动态链接或静态链接”决策时的速度以外的因素,你会好得多。例如,如果您需要使应用程序更易于部署,静态链接可能值得考虑,特别是对于不同的用户环境。或者,动态链接可能是更好的选择(特别是如果这些共享库不是您自己的),因为您的应用程序将自动获得对其调用的任何共享库进行升级的好处,而无需抬起手指。


编辑: Microsoft提出了prefer dynamic linking over static linking的具体建议:

  

不建议重新分发   静态的C / C ++应用程序   链接到Visual C ++库。它是   经常错误地认为是   将您的程序静态链接到   可以使用Visual C ++库   显着提高了性能   一个申请。然而影响   关于动态加载的性能   Visual C ++库是无关紧要的   在几乎所有情况下。此外,   静态链接不允许   服务应用程序及其   依赖库由   应用程序的作者或Microsoft。对于   例如,考虑一个应用程序   与某个特定的静态链接   库,在客户端计算机上运行   使用此库的新版本。   该应用程序仍使用来自的代码   该库的先前版本,   并没有受益于图书馆   改进,例如安全性   增强。 C / C ++的作者   强烈建议申请   仔细思考服务方案   在决定静态链接之前   依赖库,并使用动态   尽可能链接。

答案 1 :(得分:5)

这取决于磁盘的状态以及DLL是否可以在其他进程中使用。当您的程序及其DLL之前从未加载时,会发生冷启动。没有DLL的EXE具有更快的冷启动,因为只需要找到一个文件。你必须有一个非常碎片的磁盘几乎已经完全没有这种情况。

当DLL已经在另一个进程中加载​​时,它可以开始获得回报。现在,DLL的代码页只是共享,启动开销非常低,内存使用效率很高。

有点类似的情况是热启动,这是一个启动,其中DLL在上次使用时仍然可以在文件系统缓存中使用。在缓慢的磁盘上,冷启动和热启动之间的区别可能非常显着。每个人都喜欢SSD的原因之一。

相关问题