我听说启用链接时代码生成（/ LTCG开关）可以是大量项目的主要优化，这些大型项目有很多库链接在一起。我的团队在解决方案的发布配置中使用它，但编译时间长是一个真正的拖延。对其他文件依赖的文件进行一次更改会触发另外45秒的“生成代码...”。发布速度肯定比调试要快得多，但我们可以通过禁用LTCG并将O2/O2打开来实现相同的加速。Link-Time Code Generation的优点和缺点是什么？ （VS 2005）
是否值得离开/启用LTCG？
这很难说，因为这主要取决于你的项目 - 当然用VS2005（我没有与判断足够的经验）提供的LTCG的质量。最后，你必须测量。
但是，我想知道为什么在发布版本的额外持续时间中有这么多问题。您应该只交出具有可重现或存档来源的可重复，稳定，版本化的二进制文件。我很少看到频繁增量发布构建的原因。
一个团队推荐的设置是这样的： 开发人员通常只创建增量调试版本在他们的机器。构建发布版应该是从源代码管理到可再发行版（二进制文件或甚至设置）的完整版本，具有新版本号和标记/存档来源。只有这些应该给予内部测试人员/客户。
理想情况下，你将完整的构建移到一个单独的机器，或者一个虚拟机一个不错的PC机上。这为您的构建提供了稳定的环境（包括第三方库，环境变量等）。
理想地，这些构建应该自动化（“从源控制设置点击”），并应每天运行。
我也没有看到使用链接时代码生成与发布版本的额外编译时间的问题。我每天只建立一次发布版本（一夜之间），并在一天中使用单元测试和调试版本。
我知道在Bungie的家伙用它HALO3，他们提到的唯一CON是，它有时会搞砸了自己的确定性重播数据。
你是否分析了你的代码并确定了这个需求？实际上，我们几乎完全在调试模式下运行我们的服务器，但特殊情况下有几个文件被描述为性能至关重要。这很好，并且在有问题时可以调试。
不知道你在做什么样的应用程序，但是分解数据结构以对应它们在代码中处理的方式（以获得更好的缓存一致性）对我们来说是一个更大的胜利。
它允许连接器来代码的实际编译，因此它可以做更多的优化，如内联。
如果不使用LTCG，编译器是构建过程中的唯一可以内联函数的组件，例如用函数的内容替换“调用”函数，这通常是很多更快。无论如何，编译器只会这样做，以获得改进。
因此，它只能使用它的主体。这意味着如果cpp文件中的某个函数调用另一个函数，该函数没有在同一个cpp文件中实现（或者包含在头文件中），那么它没有实际的函数体，因此不能内联它。
但是，如果您使用LTCG，它是进行内联的链接器，它具有整个项目的所有cpp文件中的所有功能，减去未使用LTCG构建的引用的lib文件。这使链接器（它成为编译器）有更多的工作要做。
但它也会让你的构建花费更长时间，特别是在进行增量更改时。您可能想要在发布版本配置中打开LTCG。
请注意，LTCG与轮廓引导优化不同。
我发现缺点是编译时间更长，并且在该模式（LTCG打开）下制作的.obj文件可能非常庞大。例如，可能为200-500k的.obj文件大约为2-3mb。这只是发生在我身上，编译我的链中的一堆项目导致了一个2 GB的文件夹，其中大部分是.obj文件。
`构建一个版本应该是一个从源代码控制到可再发行（二进制文件甚至是设置）的完整版本，具有新的版本号和标签/存档来源`这不是与' LTCG的使用限制“（本文）（https://msdn.microsoft.com/zh-cn/library/bb985904.aspx）作者：Matt Pietrek（重点是我的）：..待续 – Belloc 2017-08-22 20:49:30