我有一个大型的c ++项目（g ++ / linux），其中包含大量代码生成，其中构建系统按深度= 1的目录名称将生成的代码分组到.so文件中
在释放较小的块时，这会引起一些问题，因此我尝试使其更精细，即depth = 5，这将增加.so文件的数量（5倍，从20到100），但允许我们进行更改并更精细地部署
在干净的构建过程中，当一切从头开始构建时，拥有许多小的.so文件是否会影响链接时间？
最佳答案
这是关于GNU / Linux的吗？当前动态链接非常慢，因为依赖项排序使用的算法大约为O（n³）或大约：
RFE: Improve performance of dynamic loader for deeply nested DSO dependencies
我们应该真正解决此问题，但尚未发生。 （有些人担心在依赖关系图中存在循环时更改排序顺序，这就是为什么很困难。）如果只有几十个共享对象，则不会看到加载时间的影响，但可能是如果您有100个或更多，则会出现问题。
关于您有关链接编辑器性能的原始问题：ELF的一个令人好奇的方面是，您可以链接到不包含任何符号的虚拟DSO，然后在运行时通过-Wl,--unresolved-symbols=ignore-all和复制的空DSO将其替换为适当的DSO。需要依赖项的所有soname。此技巧可以使您并行链接大多数内容，而无需考虑运行时依赖性。对于生产版本，这可能不是一个好主意，尤其是在使用延迟绑定的情况下，但是在开发过程中，这可能会有所帮助。进行此更改后，将内容拆分为许多小型DSO可能不值得（但这实际上取决于您当前正在处理的库大小）。
还请记住，DSO的部分升级可能会非常痛苦，一旦用户这样做，您就需要谨慎地管理依赖关系并维护整个系统的ABI兼容性。对于小型DSO，您还必须更频繁地处理将符号定义从一个DSO移动到另一个DSO的问题，如果使用符号版本，则会遇到奇怪的障碍。
关于c++ - 链接哪个更快？是许多小的.so文件，还是很少的大型.so文件？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/45389148/