静态链接与动态链接 [英] Static linking vs dynamic linking

问题描述

在某些情况下选择静态链接而不是动态链接，反之亦然，是否有任何令人信服的性能原因?我听说过或读过以下内容，但我对这个主题的了解不够，无法保证其真实性.

Are there any compelling performance reasons to choose static linking over dynamic linking or vice versa in certain situations? I've heard or read the following, but I don't know enough on the subject to vouch for its veracity.

1) 静态链接和动态链接在运行时性能上的差异通常可以忽略不计.

1) The difference in runtime performance between static linking and dynamic linking is usually negligible.

2) (1) 如果使用分析编译器使用分析数据优化程序热路径，则不正确，因为通过静态链接，编译器可以优化您的代码和库代码.使用动态链接只能优化您的代码.如果大部分时间都花在运行库代码上，这会产生很大的不同.否则，(1) 仍然适用.

2) (1) is not true if using a profiling compiler that uses profile data to optimize program hotpaths because with static linking, the compiler can optimize both your code and the library code. With dynamic linking only your code can be optimized. If most of the time is spent running library code, this can make a big difference. Otherwise, (1) still applies.

推荐答案

• 动态链接可以减少总资源消耗(如果多个进程共享同一个库(当然包括相同"中的版本)).我相信这是促使它在大多数环境中出现的论据.这里的资源"包括磁盘空间、RAM 和缓存空间.当然，如果您的动态链接器不够灵活，则存在DLL 地狱的风险.
• 动态链接意味着错误修复和库升级传播以改进您的产品，而无需您运送任何东西.
• 插件总是需要动态链接.
• 静态链接，意味着您可以知道代码将在非常有限的环境中运行(在启动过程的早期，或在救援模式下).
• 静态链接可以使二进制文件更容易分发到不同的用户环境(代价是发送一个更大、更耗资源的程序).
• 静态链接可能允许稍微更快的启动时间，但这在某种程度上取决于您的程序的大小和复杂性以及操作系统加载策略的详细信息.
• Dynamic linking can reduce total resource consumption (if more than one process shares the same library (including the version in "the same", of course)). I believe this is the argument that drives it its presence in most environments. Here "resources" includes disk space, RAM, and cache space. Of course, if your dynamic linker is insufficiently flexible there is a risk of DLL hell.
• Dynamic linking means that bug fixes and upgrades to libraries propagate to improve your product without requiring you to ship anything.
• Plugins always call for dynamic linking.
• Static linking, means that you can know the code will run in very limited environments (early in the boot process, or in rescue mode).
• Static linking can make binaries easier to distribute to diverse user environments (at the cost of sending a larger and more resource hungry program).
• Static linking may allow slightly faster startup times, but this depends to some degree on both the size and complexity of your program and on the details of the OS's loading strategy.

一些编辑以在评论和其他答案中包含非常相关的建议.我想指出的是，你打破这个的方式很大程度上取决于你计划在什么环境中运行.最小的嵌入式系统可能没有足够的资源来支持动态链接.稍微大一点的小型系统可能很好地支持动态链接，因为它们的内存小到足以使动态链接节省的 RAM 非常有吸引力.正如 Mark 所言，成熟的消费类 PC 拥有大量资源，您可能可以让便利性问题驱动您对此问题的思考.

Some edits to include the very relevant suggestions in the comments and in other answers. I'd like to note that the way you break on this depends a lot on what environment you plan to run in. Minimal embedded systems may not have enough resources to support dynamic linking. Slightly larger small systems may well support dynamic linking, because their memory is small enough to make the RAM savings from dynamic linking very attractive. Full blown consumer PCs have, as Mark notes, enormous resources, and you can probably let the convenience issues drive your thinking on this matter.

解决性能和效率问题:这取决于.

To address the performance and efficiency issues: it depends.

传统上，动态库需要某种粘合层，这通常意味着函数寻址中的双重分派或额外的间接层，并且可能会降低速度(但函数调用时间实际上是您运行时间的很大一部分吗???).

Classically, dynamic libraries require a some kind of glue layer which often means double dispatch or an extra layer of indirection in function addressing and can cost a little speed (but is function calling time actually a big part of your running time???).

但是，如果您运行的多个进程都大量调用同一个库，则在使用动态链接相对于使用静态链接时，您最终可以节省缓存行(从而赢得运行性能).(除非现代操作系统足够聪明，可以注意到静态链接二进制文件中的相同段.似乎很难，有人知道吗?)

However, if you are running multiple processes which all call the same library a lot, you can end up saving cache lines (and thus winning on running performance) when using dynamic linking relative to using static linking. (Unless modern OS's are smart enough to notice identical segments in statically linked binaries. Seems hard, anyone know?)

另一个问题:加载时间.您在某个时候支付装载费用.您何时支付此费用取决于操作系统的工作方式以及您使用的链接.也许你宁愿推迟支付，直到你知道你需要它.

Another issue: loading time. You pay loading costs at some point. When you pay this cost depends on how the OS works as well as what linking you use. Maybe you'd rather put off paying it until you know you need it.

请注意，静态与动态链接传统上不是优化问题，因为它们都涉及单独编译到目标文件.但是，这不是必需的:原则上，编译器可以最初将静态库"编译"为消化后的 AST 形式，然后通过将这些 AST 添加到为主代码生成的 AST 来链接"它们，从而实现全局优化.我使用的系统都没有这样做，所以我无法评论它的工作情况.

Note that static-vs-dynamic linking is traditionally not an optimization issue, because they both involve separate compilation down to object files. However, this is not required: a compiler can in principle, "compile" "static libraries" to a digested AST form initially, and "link" them by adding those ASTs to the ones generated for the main code, thus empowering global optimization. None of the systems I use do this, so I can't comment on how well it works.

回答性能问题的方法总是通过测试(并尽可能使用类似于部署环境的测试环境).

The way to answer performance questions is always by testing (and use a test environment as much like the deployment environment as possible).

这篇关于静态链接与动态链接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！