链接哪个更快？ 是许多小的.so文件，还是很少的大型.so文件？

Question

我有一个大型的c ++项目（g ++ / linux），其中包含大量代码生成，其中构建系统按深度= 1的目录名称将生成的代码分组到.so文件中

在释放较小的块时，这会引起一些问题，因此我尝试使其更精细，即depth = 5，这将增加.so文件的数量（5倍，即20到100），但允许我们进行更改并更精细地部署

在干净的构建过程中，当一切从头开始构建时，拥有许多小的.so文件是否会影响链接时间？

Answer 1

这是关于GNU / Linux的吗？ 动态链接是目前非常慢，因为依赖分拣使用一种算法其大约为O（n³）或其附近：

• RFE：针对深层嵌套的DSO依赖关系，提高动态加载程序的性能

我们应该真正解决此问题，但尚未发生。 （某些人担心在依赖关系图中存在循环时更改排序顺序，这就是为什么很难做到这一点。）如果只有几十个共享对象，则不会看到加载时间的影响，但可能是如果您有100个或更多，则会出现问题。

关于您有关链接编辑器性能的原始问题：ELF的一个令人好奇的方面是，您可以链接到不包含任何符号的虚拟DSO，然后在运行时通过-Wl,--unresolved-symbols=ignore-all将其替换为适当的DSO。 -Wl,--unresolved-symbols=ignore-all ，将空DSO复制到您需要依赖的所有soname。 此技巧可以使您并行链接大多数内容，而无需考虑运行时依赖性。 对于生产版本，这可能不是一个好主意，特别是如果您使用延迟绑定，但是在开发过程中，这可能会有所帮助。 进行此更改后，将内容拆分为许多小的DSO可能不值得（但这实际上取决于您当前正在处理的库大小）。

还请记住，DSO的部分升级可能会非常痛苦，一旦用户这样做，您就需要谨慎地管理依赖关系并维护整个系统的ABI兼容性。 对于小型DSO，您还必须更频繁地处理将符号定义从一个DSO移到另一个DSO的问题，如果使用符号版本，则会遇到奇怪的障碍。