链接哪个更快？很多小的.so文件还是几个大的.so文件？ 我有一个大型C++项目G++/Linux，代码生成很多，其中生成系统将生成的代码按深度= 1的目录名分组到.so文件中。

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

---

在一个干净的构建过程中，当所有东西都是从头开始构建的时候，有很多小的.so文件会影响链接时间吗？

这是关于GNU/Linux的吗？动态链接目前速度非常慢，因为依赖项排序使用的算法大约等于或等于：

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

关于您最初关于链接编辑器性能的问题：ELF的一个有趣方面是，您可以针对不包含任何符号的虚拟DSO进行链接，并在运行时通过-Wl，-unresolved symbols=ignore all和一个复制到所有需要依赖项的sonames的空DSO替换该DSO。这个技巧可以让您并行链接大多数内容，而不考虑运行时依赖关系。对于生产构建来说，这可能不是一个好主意，尤其是当您使用惰性绑定时，但在开发过程中，它可能会有所帮助。有了这一变化，将内容拆分为许多小型DSO可能不值得，但这实际上取决于您当前处理的库的大小

---

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

您尝试过吗？每个项目可能会有所不同。我觉得这个问题有点太宽泛了。不过，如果让我猜的话，我可能会想象它会变慢。我现在正在尝试。细粒度版本的好处超过了编译时间的增加，但是在一台具有64GB内存的40核机器上完全构建代码已经需要一个多小时。dll粒度的标准应该是可执行文件之间的机器代码共享。如果您正在为构建时间而挣扎，那么您应该检查代码的组织和构建时间。整个故事听起来就像你只是在使用一个写得很糟糕的codegen，它无缘无故地发出数千个翻译单元。我正在检查代码组织，我将在.so文件处拆分。然而，我想知道其他人是否有做类似事情的经验