静态链接的可执行文件比动态链接的可执行文件更快吗？
由于动态链接库必须在运行时解析，因此静态链接的可执行文件比动态链接的可执行文件更快吗？
Since the dynamically linked libraries have to be resolved at run-time, are statically linked executables faster than dynamically linked executables?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
静态链接生成的可执行文件比动态链接更大，因为它必须将所有库代码直接编译为可执行文件。这样做的好处是减少了开销，不再需要从库中调用函数，并且加载时间明显加快。
动态链接的可执行文件会更小，因为它在运行时调用共享代码库。这样做有几个好处，但从速度或优化的角度来看，最重要的是减少了磁盘空间和内存消耗量，并且由于减少了总资源消耗（特别是在 Windows 中）而改进了多任务处理）。
所以这是一种权衡：有争论为什么其中任何一个可能会稍微快一些。这取决于很多不同的因素，例如程序中速度关键的例程在多大程度上依赖于对库函数的调用。但上述声明中要强调的重要一点是，它可能会稍微快一些。 速度差异几乎难以察觉，甚至与正常的预期波动也难以区分。
如果您真的关心，请对其进行基准测试并查看。但我建议这是浪费时间，并且有更有效和更重要的方法来提高应用程序的速度。从长远来看，在做出“动态链接或静态链接”决定时，考虑速度以外的因素会更好。例如，如果您需要使应用程序更易于部署，特别是对于不同的用户环境，则静态链接可能值得考虑。或者，动态链接可能是更好的选择（特别是如果这些共享库不是您自己的），因为您的应用程序将自动获得对其调用的任何共享库进行升级的好处，而无需费力。
编辑： Microsoft 提出具体建议，您更喜欢动态链接而不是静态链接：
Static linking produces a larger executable file than dynamic linking because it has to compile all of the library code directly into the executable. The benefit is a reduction in overhead from no longer having to call functions from a library, and anywhere from somewhat to noticeably faster load times.
A dynamically linked executable will be smaller because it places calls at runtime to shared code libraries. There are several benefits to this, but the ones important from a speed or optimization perspective are the reduction in the amount of disk space and memory consumed, and improved multitasking because of reduced total resource consumption (particularly in Windows).
So it's a tradeoff: there are arguments to be made why either one might be marginally faster. It would depend on a lot of different things, such as to what extent speed-critical routines in the program relied on calls to library functions. But the important point to emphasize in the above statement is that it might be marginally faster. The speed difference will be nearly imperceptible, and difficult to distinguish even from normal, expected fluctuations.
If you really care, benchmark it and see. But I advise this is a waste of time, and that there are more effective and more important ways to increase your application's speed. You will be much better off in the long run considering factors other than speed when making the "to dynamically link or to statically link" decision. For example, static linking may be worth considering if you need to make your application easier to deploy, particularly to diverse user environments. Or, dynamic linking may be a better option (particularly if those shared libraries are not your own) because your application will automatically reap the benefits of upgrades made to any of the shared libraries that it calls without having to lift a finger.
EDIT: Microsoft makes the specific recommendation that you prefer dynamic linking over static linking:
这取决于磁盘的状态以及 DLL 是否可以在其他进程中使用。当您的程序及其 DLL 以前从未加载过时，就会发生冷启动。没有 DLL 的 EXE 冷启动速度更快，因为只需要找到一个文件。您必须有一个碎片严重且几乎已满的磁盘才能避免出现这种情况。
当 DLL 已被加载到另一个进程中时，它就可以开始发挥作用。现在DLL的代码页被简单地共享，启动开销非常低并且内存使用效率很高。
一个有点类似的情况是热启动，即启动时 DLL 在文件系统缓存中仍可使用上次使用的版本。在缓慢的磁盘上，冷启动和热启动之间的差异可能非常显着。每个人都喜欢 SSD 的原因之一。
It depends on the state of your disk and whether or not the DLLs might be used in other processes. A cold start happens when your program and its DLLs were never loaded before. An EXE without DLLs has a faster cold start since only one file needs to be found. You would have to have a badly fragmented disk that's almost full to not have this case.
A DLL can start to pay off when it is already loaded in another process. Now the code pages of the DLL are simply shared, startup overhead is very low and memory usage is efficient.
A somewhat similar case is a warm start, a startup where the DLL is still available in the file system cache from a previous time it was used. The difference between a cold and a warm start can be quite significant on a sluggish disk. The one reason that everybody likes a SSD.
不，我不这么认为。在大多数情况下，每个程序只有内存中的库副本会使整个系统占用更少的内存。假设您有 100 个程序静态使用 libc 库，而 libc 约为 2-3MB，因此它会使程序的大小增加。
但同样在动态中我们可以共享东西，所以内存中的字节越少意味着缓存中的字节越多，缓存中的字节越多意味着速度更快。
尽管它有加载开销，但您的整体系统性能更快。
No, I don't think so. in most of the cases only a copy of the library in memory per program makes the overall system less memory. suppose you have 100 programs using the libc library statically, and libc is ~2-3MB, so it makes the size of the program increase.
But same in a dynamic we can share stuff, so fewer bytes in the memory means more bytes in Caches, More bytes in cache means faster.
Though it has loading overhead, your overall system performance is faster.