根据我的理解，创建具有多个编译单元的程序的主要好处是组件的可重用性和合并小更改时编译时间更短。
我还认为(可能是错误的)与此相关的惩罚是，在它们自己的编译单元中定义的函数不能声明为“内联”。
[我认识到这个关键字实际上并没有强制编译器内联扩展函数，但我的理解是它为编译器提供了更大的优化灵 active ，因此值得尽可能包括在内。]
到目前为止还好吗？
我真正的问题是，当程序正在解决一个复杂的建模问题时，成本/ yield 分析是否仍然支持多个编译单元，并且需要在集群上迭代其主循环数月以生成有用的输出。
假设一个多编译单元程序需要几分钟的时间来编译，而同一个程序重新配置为单个编译单元需要几个小时来编译......如果单个编译单元将所有函数声明为内联并因此呈现更多的优化机会，我认为执行时间可以减少几个百分点，而不是弥补额外的编译时间，这似乎是合理的。
对于这种情况是否有好的经验法则，或者它是否在很大程度上取决于情况？
最佳答案
正如其他人所说，将程序分解为不同编译单元的主要好处是可读性。 更短的编译时间在某种程度上是这个想法的一个很好的副作用。
如果你关心内联，你可以求助于Link Time Code Generation and Link-Time Optimization .将程序分解为编译单元和 LTO 的组合看起来是理想的解决方案，尽管尚不清楚当函数的完整定义可用时编译器执行的优化类型是否可以由 LTO 执行。 例如，我不知道 LTO 是否可以支持 C++ 中的返回值优化，因为它是在高抽象层次上完成的。需要进行性能测试。 (编辑:即使在没有 LTO 和此类高级技巧的情况下，至少在 gcc 和 clang [我试过] 上，RVO 也会执行。最有可能的是，这种优化是通过更改函数的 ABI 来执行的，它带有一个指向必须在函数中构造和返回的对象的“隐藏指针”。)
第三个值得研究的解决方案是使用类似 sqlite amalgamation 的方法。 ，将不同的编译单元放入一个巨大的 .c 文件中的过程。 不过，这看起来像是需要大量用户构建的基础设施。
关于c++ - 当(执行时间)>>>(编译时间)时，多个编译单元是否仍然值得？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11663497/