我听说启用链接时代码生成(/ LTCG交换机)可以成为大型项目的主要优化,其中有许多库链接在一起.我的团队正在我们的解决方案的Release配置中使用它,但是长编译时间是一个真正的拖累.对其他文件所依赖的一个文件进行一次更改会触发另一个45秒的"生成代码...".发布肯定比Debug快得多,但是我们可以通过禁用LTCG并且只保留/ O2来实现相同的加速.
启用/ LTCG是否值得？
很难说,因为这主要取决于你的项目 - 当然还有VS2005提供的LTCG的质量(我没有足够的经验来判断).最后,你必须衡量.
但是,我想知道为什么你在发布版本的额外持续时间内遇到那么多问题.您应该只分发具有可重现或归档源的可重现,稳定,版本化的二进制文件.我很少看到频繁的增量版本构建的原因.
团队的推荐设置是:开发人员通常只在其计算机上创建增量调试版本.构建版本应该是从源代码控制到可再发行(二进制文件甚至设置)的完整构建,具有新版本号并标记/归档源.只有这些应该给内部测试人员/客户.
理想情况下,您可以将完整版本移动到单独的计算机上,也可以将计算机上的虚拟机移动.这为您的构建(包括第三方库,环境变量等)提供了稳定的环境.
理想情况下,这些构建应该是自动化的("从源代码控制到设置一键"),并且应该每天运行.
它允许链接器进行代码的实际编译,因此它可以进行更多优化,例如内联.
如果不使用LTCG,编译器是构建过程中唯一可以内联函数的组件,就像用函数内容替换函数的"调用"一样,这通常要快得多.无论如何,编译器只会对这会产生改进的函数这样做.
因此它只能通过它具有身体的功能来实现.这意味着如果cpp文件中的函数调用另一个未在同一cpp文件中实现的函数(或在包含的头文件中),则它没有该函数的实际主体,因此不能内联它.
但是如果你使用LTCG,它就是内联的链接器,并且它具有整个项目的所有cpp文件中的所有函数,减去了未使用LTCG构建的引用的lib文件.这使得链接器(它成为编译器)可以使用更多.
但它也会使您的构建需要更长时间,尤其是在进行增量更改时.您可能希望在发布版本配置中打开LTCG.
请注意,LTCG与配置文件引导的优化不同.
京公网安备 11010802040832号 | 京ICP备19059560号-6 