我听说启用链接时间代码生成（/LTCG 开关）对于具有大量要链接在一起的库的大型项目来说是一项重大优化。我的团队在我们的解决方案的发布配置中使用它，但是长编译时间是一个真正的拖累。对没有其他文件依赖的一个文件的一次更改会触发另外 45 秒的“正在生成代码...”。 Release 肯定比 Debug 快得多，但我们可以通过禁用 LTCG 并仅打开 /O2 来实现相同的加速。
启用 /LTCG 是否值得？
【问题讨论】：
标签： c++ visual-c++
很难说，因为这主要取决于你的项目——当然还有 VS2005 提供的 LTCG 的质量（我没有足够的经验来判断）。最后，你必须衡量。
但是，我想知道为什么您对发布构建的额外持续时间有这么多问题。您应该只分发具有可重现或存档源的可重现、稳定、版本化的二进制文件。我很少看到频繁的增量发布构建的原因。
建议的团队设置如下： 开发人员通常只在他们的机器上创建增量调试版本。构建版本应该是从源代码控制到可再分发（二进制文件甚至设置）的完整构建，具有新的版本号并标记/归档源。只有这些应该提供给内部测试人员/客户。
理想情况下，您会将完整的构建移至单独的计算机，或者可能是一台好 PC 上的虚拟机。这为您的构建提供了一个稳定的环境（包括第 3 方库、环境变量等）。
理想情况下，这些构建应该是自动化的（“一键从源代码管理到设置”），并且应该每天运行。
【讨论】：
Building a release should be a complete build from source control to redistributable (binaries or even setup), with a new version number and labeling/archiving the sources 这是否与 Matt Pietrek 在this article 上的“限制 LTCG 使用”一节中所写的内容相矛盾（重点是我的）：.. 待续。
它允许链接器对代码进行实际的编译，因此它可以做更多的优化，例如内联。
如果您不使用 LTCG，编译器是构建过程中唯一可以内联函数的组件，例如用函数的内容替换对函数的“调用”，这通常会快很多.无论如何，编译器只会对产生改进的函数这样做。
因此，它只能使用它拥有的函数来执行此操作。这意味着如果 cpp 文件中的一个函数调用另一个未在同一个 cpp 文件（或包含的头文件）中实现的函数，则它没有函数的实际主体，因此不能内联它.
但是，如果您使用 LTCG，它是执行内联的链接器，并且它具有整个项目的所有 cpp 文件中的所有功能，减去未使用 LTCG 构建的引用的 lib 文件。这为链接器（成为编译器）提供了更多的工作空间。
但这也会使您的构建花费更长的时间，尤其是在进行增量更改时。您可能希望在发布构建配置中打开 LTCG。
请注意，LTCG 与配置文件引导优化不同。
【讨论】：
我知道 Bungie 的人将它用于 Halo3，他们提到的唯一缺点是它有时会弄乱他们的确定性回放数据。
您是否已对您的代码进行了概要分析并确定了对此的需求？我们实际上几乎完全在调试模式下运行我们的服务器，但在特殊情况下，一些文件被描述为性能关键。效果很好，并且在出现问题时可以调试。
不确定您正在制作什么样的应用程序，但分解数据结构以对应于它们在代码中的处理方式（为了更好的缓存一致性）对我们来说是一个更大的胜利。
【讨论】：
我发现缺点是编译时间较长，并且在该模式下（LTCG 打开）生成的 .obj 文件可能非常庞大。例如，可能为 200-500k 的 .obj 文件大约为 2-3mb。我碰巧在我的链中编译一堆项目导致了一个 2 GB 的文件夹，其中大部分是 .obj 文件。
【讨论】：
我也没有看到在发布版本中使用链接时代码生成额外编译时间的问题。我每天只构建一次发布版本（通宵），并在白天使用单元测试和调试构建。
【讨论】：