Hun*_*der 24 dll performance linker dynamic-linking static-linking
由于动态链接库必须在运行时解析,静态链接的可执行文件是否比动态链接的可执行文件更快？
Cod*_*ray 18
静态链接产生比动态链接更大的可执行文件,因为它必须将所有库代码直接编译到可执行文件中.这样做的好处是可以减少不再需要从库中调用函数的开销,以及从某种程度到明显更快的加载时间.
动态链接的可执行文件将更小,因为它将运行时调用放置到共享代码库.这有几个好处,但从速度或优化的角度来看,重要的是减少磁盘空间和内存消耗量,并改善多任务处理,因为减少了总资源消耗(特别是在Windows中).
所以这是一个权衡:有人争论为什么其中任何一个可能会略微加快.它取决于许多不同的东西,例如程序中速度关键例程在多大程度上依赖于对函数库的调用.但在上述陈述中要强调的重点是,它可能会略微加快.速度差异几乎难以察觉,甚至难以区分正常的预期波动.
如果你真的在乎,请对它进行基准测试.但我建议这是浪费时间,并且有更有效和更重要的方法来提高应用程序的速度.从长远来看,考虑到"动态链接或静态链接"决策时的速度以外的因素,你会好得多.例如,如果您需要使应用程序更易于部署,静态链接可能值得考虑,特别是对于不同的用户环境.或者,动态链接可能是更好的选择(特别是如果这些共享库不是您自己的),因为您的应用程序将自动获得对其调用的任何共享库进行升级的好处,而无需抬起手指.
编辑: Microsoft提出您更喜欢动态链接静态链接的具体建议:
建议不要重新分发静态链接到Visual C++库的C/C++应用程序.通常错误地认为通过将程序静态链接到Visual C++库,可以显着提高应用程序的性能.但是,几乎在所有情况下,动态加载Visual C++库对性能的影响都是微不足道的.此外,静态链接不允许应用程序的作者或Microsoft为应用程序及其依赖库提供服务.例如,考虑一个静态链接到特定库的应用程序,该应用程序在具有此库的新版本的客户端计算机上运行.该应用程序仍然使用此库的先前版本中的代码,并且不会受益于库改进,例如安全性增强.强烈建议C/C++应用程序的作者在决定静态链接到依赖库之前考虑服务方案,并尽可能使用动态链接.
它取决于磁盘的状态以及DLL是否可能在其他进程中使用.当您的程序及其DLL之前从未加载时,会发生冷启动.没有DLL的EXE具有更快的冷启动,因为只需要找到一个文件.您将不得不拥有一个严重碎片的磁盘几乎已满,不具备此案例.
DLL已经在另一个进程中加载时可以开始获得回报.现在简单地共享DLL的代码页,启动开销非常低并且内存使用效率很高.
一个类似的情况是热启动,一个启动,其中DLL在上次使用时仍然可以在文件系统缓存中使用.在缓慢的磁盘上,冷启动和热启动之间的区别可能非常显着.每个人都喜欢SSD的原因之一.