游戏大厂说：咱们的VS2019在链接这块比较给力

介绍

Visual Studio的C++团队一直都在努力工作，不断地做着工程编译和链接阶段的性能优化。今天这篇文章是VS性能优化系列的第二部分，我们主要会讲述现实世界中的另外两个游戏大厂的实际案例。

在这篇文章中，极限竞速4(Forza Horizon 4)开发团队分享了一份测试报告，其中对比了三种不同版本的Visual Studio的工程编译和链接时间。相比于Visual Studio 2017，最新版本的VS在链接效率这块提升了18.15倍。另外，Trun 10游戏工作室则观察到了4.95倍的链接时间优化。
随着工程构建时间的显著下降，游戏开发商Playground Games可以将编译选项从/debug:fastlink切换为/debug:full。从分析结果来看，我们不仅可以看到大量的迭代构建时间改善，而且也可以看到现实中项目整体质量的提高。

Playground Games的Andrew Sage这样说道：
“使用完全链接可以消除与快速链接相关的调试器停顿，并使我们的工程团队可以专注于调试当前版本，而不必等待开发环境开始响应。再加上构建和链接时间的整体改进，这将减少整个团队的工作流程中断并提高生产率。”

构建极限竞速4

Playground Games的极限竞速4团队使用Incredibuild的构建监视器来测量构建时间。监视器显示该构建过程中的每个阶段所花费的时间。编译时间是从在第一个文件编译开始至链接之前进行测量的。链接时间是从链接步骤开始到链接步骤结束之间的时间。总时间则是Incredibuild从开始到结束的整个时间。构建总时间可能比编译和链接时间的总和还长，因为测量中包括一些启动和后链接步骤。

为了确保并行编译不受网络负载的影响，在工作室的空闲时间进行了测试。为了进一步减少数据中的噪音，我们对所有运行进行了平均测试，并在所有硬盘驱动器活动均已完成并且Intellisense已完成解析之后才开始测试。

测试结果：Version 15.9.4 /debug:fastlink vs 16.8 /debug:full
比较Visual Studio 2017中的/debug:fastlink和Visual Studio 2019中的/debug:full，我们看到了实际项目质量的整体提高。乍一看，总时间提高了1.26倍。但是，通过切换到/debug：full，每个调试会话可节省多达30-45秒的时间，从而大大提高了生产率。Playground Games的工程师已切换到/debug:full，以便能获得更短的构建时间并利用/debug:full提供的更快的调试体验。

Version 15.9.4 vs 16.8 using /debug:full
在第二个测试中，我们比较了使用Visual Studio的3个版本的/debug:full构建。编译时间提高了1.52倍。进行完全重建时，编译时间从Visual Studio 2017中的4分钟39秒减少到Visual Studio 2019 16.8中的3分钟5秒。对于单个文件更改，我们观察到减少了19秒。平均而言，链接时间提高了18.15倍。Visual Studio 2019 16.8中的完整重建链接时间减少了10分钟18秒，这是一个巨大的改进。

构建竞速飞驰
在Turn 10 Studios工作室中，竞速飞驰开发团队使用MSBuild的结构化日志查看器来获取构建和编译时间。下面的每个时间都是4次运行的平均值的结果。CL表示cl.exe（MSVC编译器），而Lib表示lib.exe（Microsoft库管理器）。尽管Full Build表示总时间，但选择了Debug，CL和Lib时间进行展示，每次均单独取平均值。

测试结果：Version 15.9 vs 16.7 Profile Build with /debug:fastlink
当使用/debug:fastlink进行完整的Profile构建时，我们可以看到构建时间有所改善，而链接时间却缩短了1.96倍，库打包时间减少了9.34倍。

Version 15.9 vs 16.7 Profile Build with /debug:fulllink
使用/debug:fulllink，我们可以看到更有利的数字。现在，完整构建时间快了1.71倍。同样，链接时间也缩短了4.95倍，库打包时间也提高了10.86倍。

Version 15.9 vs 16.7 Release Build
对于发布版本，我们看到了与上述类似的改进。构建时间减少了1.81倍，链接时间减少了2.44倍。

分析
显着的构建迭代时间缩短是C++团队进行优化工作的直接结果。通过加快程序数据库(PDB)文件生成和类型合并的速度，在16.0和16.2版中改进了链接器性能。16.6中的算法更改和更坏的情况16.7中的增量链接改进改进了链接器性能的优化。在16.8版中，PDB文件的多线程生成进一步提高了性能。 在后面的文章中，我们还会详细介绍16.8的改进。

开发者访谈

我们与Playground Games(极限竞速4)的Andrew Sage和Turn 10 Studios(竞速飞驰)的Dan Tunnell进行了交谈，以了解改进对工作室的影响。

问：现在你们工作室正在使用Visual Studio 2019吗？
答(Andrew)：
根据每个人的机器配置，我们混合使用VS2017和VS2019。大多数工程师已将VS2019作为主要开发环境，但我们仍有一些工具项目尚未更新，仍在使用2017。

答(Dan):
我们只是在2021年1月的最后一周将整个工作室迁移到了Visual Studio 2019，自假期开始以来，我们就有一个开发分支机构在运行它，但几天前它才被广泛采用。

问：从更快的链接时间中你们看到了哪些直接的好处？
答(Andrew)：
减少构建和测试变更的迭代时间使我们的生产率更高，尤其是在每天多次遍及所有工程师的过程中获得的收益方面。
主要优点是消除了在切换到完整链接时使用快速链接进行调试时的停顿，因为每个调试会话将增加30-45秒的时间，每个构建过程可以重复多次。

答(Dan):
我看到的最大好处是缩短了迭代时间。即使我们仅将链接时间缩短了30秒，将其乘以工作室中的开发人员数量以及他们每天编译的次数，也会变得非常有效率。

问：从长期来看，此次优化有哪些潜在的好处呢？
答(Andrew)：
从长远来看，我们还将所有自动化构建服务器移至Visual Studio 2019，以减少构建验证和测试周转时间。 这意味着从签入代码到知道构建成功的时间减少了。另外，由于这些构建连续运行，因此每个构建的更改较少。将来将我们所有的工具项目移至Visual Studio 2019将为工具团队带来进一步的生产力提升，以及他们花费更多时间支持我们的内容创建者的能力。

答(Dan):
长期的好处之一是减少了我们服务器场上的构建时间。如果有人签入破坏构建的代码，我们越快地捕获它，我们遇到的停机时间就越短。 由于减少了开发人员签入新工具代码与构建系统签入新工具二进制文件之间的时间，因此它还使我们能够更快地进行工具迭代。 此外，“验证”构建的时间减少了。 在签入之前，每个开发人员都会构建一个具有代表性的游戏二进制文件样本，以确保他们没有破坏任何东西。这会减慢迭代速度（我敢肯定，你会看到一种模式逐渐呈现出来-迭代时间为准），我们为加快速度所做的一切都非常有价值。

链接时间的改善如何改变工作室的工作流程模式？
答(Andrew)：
除了改进重点放在解决问题上，而不是等待整个团队完成构建之外，我认为我们将能够专注于其他生产率的提高，这将在我们的流程中占更大的比例。例如，即使使用更快的工具集和分布式构建系统，减少代码库中的依赖关系也可以缩短构建时间，并且将来我们将继续致力于这一领域。另外，使用完整链接可以减少因停顿而引起的精神上的“任务切换”开销，因为当有人撞到停顿时，他们可能会切换到另一个任务，然后再返回，这可能导致工作流中断。

答(Dan):
如果我猜到了，我会说我们会减少构建中断的时间。验证版本需要大量时间才能完成，即使有必要，有时开发人员也会在急忙的情况下忽略该步骤，并确信他们的修复很琐碎应该没什么问题。构建时间越快，进入障碍就越小，即使对于他们认为微不足道或看起来没问题的更改，人们也更可能执行该步骤。我还认为，编译之间的代码更改可能会更少。 编译和链接时间越长，开发人员在点击按钮进行编译之前将需要添加的代码越多。如果编译和链接几乎是瞬时的，那么大多数开发人员会将其用作快速的完整性检查，以验证方法/函数/类/等。他们只是在继续之前添加了编译。

总结
至此，已经有三家游戏大厂见证了VS2019的”好处”。
我现在做的东西还非常小，以至于我还感受不到这些”好处”。
希望有一天，我可以感受到这些”好处”。
劲酒虽好，我一定要贪杯。

最后
Microsoft Visual C++团队的博客是我非常喜欢的博客之一，里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙，如果你对Visual C++这门古老的技术还是那么感兴趣，则可以经常去他们那(或者我这)逛逛。
本文来自：《Playground Games and Turn 10 Studios See 18.2X and 4.95X Link Time Improvements Respectively on Visual Studio 2019》