哪个链接更快？许多小的 .so 文件或几个大的 .so 文件？答案

【问题标题】：Which is faster to link? Many small .so files or few large .so files?哪个链接更快？许多小的 .so 文件或几个大的 .so 文件？
【发布时间】：2017-07-29 12:12:51
【问题描述】：

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

这在释放较小的块时会导致一些问题，因此我试图使其更细化，即深度=5，这将增加 .so 文件的数量（增加 5 倍，从 20 到 100）但是让我们能够在更细粒度的级别上进行更改和部署

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

【问题讨论】：

你试过了吗？它可能会因项目而异。我觉得这个问题有点太笼统了。不过，如果我猜的话，我可能会想象它会更慢。
我现在正在尝试。粒度发布的好处超过了编译时间的增加，但代码已经花费了一个多小时才能完全构建在 40 核 64GB RAM 的机器上
dll粒度的标准应该是可执行文件之间的机器码共享。如果您正在为构建时间而苦苦挣扎，那么您应该检查代码的组织和构建时间。整个故事听起来就像您只是在使用编写不佳的代码生成器，它无缘无故地发出数千个翻译单元。
我正在检查代码组织，我将拆分 .so 文件。但是，我想知道其他人是否有做类似事情的经验

标签： c++ g++ ld

【解决方案1】：

这是关于 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 复制到您需要依赖项的所有 sonames。这个技巧可以让您并行链接大多数事物，而忽略运行时依赖关系。对于生产构建来说，这可能不是一个好主意，特别是如果您使用惰性绑定，但在开发过程中，它可能会有所帮助。有了这个改变，将东西分成许多小的 DSO 可能不值得（但这实际上取决于您当前处理的库大小）。

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

【讨论】：