shared-libraries - 共享库与静态库的加载时间

Question

我有一个关于共享库与静态库加载时间的问题。

假设我有一个使用 liba、libb、libc 的可执行文件 foo.exe。同样在给定时间，机器上运行的可执行文件实例超过 10 个。

现在，如果上述 3 个库是共享库:
第一个实例被加载到 RAM 中:所用时间将是 foo.exe 的 main() 加载内存所用的时间(假设它可以忽略不计)+ 加载 liba 的时间 + 加载 libb 的时间 + 加载 libc 的时间
第二个实例已启动:现在假设运行此可执行文件的第二个实例。由于所有图书馆
已经加载到主内存中，所花费的时间仅用于将 main() 加载到可以忽略不计的内存中。

现在，如果上述 3 个库是静态库:
第一个实例被加载到 RAM 中:所用时间将是 foo.exe 的 main() 加载时间
内存(假设它可以忽略不计)+加载liba的时间+加载libb的时间+加载libc的时间(当然它现在是整个可执行文件的所有部分)
第二个实例已启动:现在假设运行此可执行文件的第二个实例。花费的时间将是
foo.exe 的 main() 再次加载内存所花费的时间(假设它可以忽略不计)+ 加载 liba 的时间 + 加载 libb 的时间 + 加载 libc 的时间。 (因为每个可执行文件都不能共享库，因为它们是静态库)

所以我的结论是，使用静态库加载时间会更长。但有人告诉我，共享库在加载过程中比静态库需要更多时间，所以会有延迟，所以共享库不是一个好的选择。这怎么可能 ？

Answer 1

链接(解析引用)不是免费的。使用静态链接，在生成二进制文件时就可以一劳永逸地完成解析。使用动态链接，每次加载二进制文件时都必须这样做。更不用说编译为在共享库中运行的代码可能比编译为静态链接的代码效率低。确切的成本取决于架构和系统的动态链接实现。

对于 32 位 x86 指令集，使库动态化的成本可能相对较高:在 ELF binary format 中，必须牺牲一个已经稀缺的寄存器来使动态链接的代码可重定位。较早的 a.out格式将每个共享库放在一个固定的位置，但这并没有扩展。我相信当动态库放置在地址空间中的预定位置时，Mac OS X 有一个中间系统，但是冲突在单个计算机的规模上得到了解决(安装新系统后的漫长的“优化系统性能”阶段)软件)。从某种意义上说，这个系统(称为 pre-binding)可以让你吃蛋糕也可以吃。
我不知道现在 Apple 几乎切换到 amd64 架构后是否还需要预绑定(bind)。

此外，在现代操作系统上，静态和动态链接的代码仅在使用时才从磁盘加载(分页)，但这与您的问题完全正交。