游乐场游戏和Turn10工作室在VisualStudio2019上的链接时间分别提高了18.2倍和4.95倍

VisualStudio的C++团队在Visual Studio 2019中提供了大量的构建和链接时间改进。这个博客是一系列博客展示了我们努力的真实世界结果的第2部分。看看 gears5团队受益于第1部分中的迭代构建时间改进。

在这个博客中，forzahorizon4团队分享了三个不同版本的visualstudio中编译和链接时间的测试结果。链接时间现在是 快18.15倍 比2017年的Visual Studio要好得多。同样的，10号弯的工作室看到了 4.95倍 提高了连接时间。建造时间的减少使得操场游戏从 /debug:fastlink 到 /debug:full . 分析结果，我们不仅可以看到大量的迭代构建时间，而且还可以看到实际生活质量的提高。

“使用完全链接可以消除与fastlink相关的调试器暂停，并允许我们的工程团队集中精力调试当前版本，而不是等待开发环境做出响应。再加上构建和链接时间的整体改进，这将减少整个团队的工作流中断和生产力改进。” –Andrew Sage来自游乐场游戏

地平线4号楼

方法论

在操场比赛中，Forza Horizon 4团队使用Incredibuild的构建监视器测量构建时间。监视器显示进程每个阶段的挂钟时间。编译时间是在第一个文件开始时测量的，在链接之前立即编译。链路时间是从链路步骤的开始到链路步骤的结束测量的。总时间（由start-to-end Incredibuild进程度量）可能长于编译时间和链接时间之和，因为度量中包含一些启动和链接后步骤。

测试是在工作室的安静时间进行的，以确保并行编译不受网络负载的影响。为了进一步减少数据中的噪音，测试在多次运行中取平均值，并在所有硬盘活动完成和Intellisense解析完成后开始。

结果

版本15.9.4/调试： 快速链接 vs 16.8/调试： 满的

比较 /debug:fastlink 在Visual Studio 2017和 /debug:full 在visualstudio中，2019演示了现实生活质量的提高。乍一看，总时间提高了一倍 1.26 ; 然而，相当长的时间 30-45秒 通过切换到保存每个调试会话 /debug:full ，从而大大提高了生产率。操场运动会的工程师们已改为 /debug:full 为了既能享受更短的构建时间，又能利用 /debug:full .

总时间（分钟）	完全重建	单个文件更改
VS2017 15.9.4/调试： 快速链接	4:22	1:39
VS2019 16.8版    /调试： 满的	3:40	1:15
快x倍	1.19	1.32
平均快x倍	1.26

版本15.9.4 vs 16.8使用/debug:full

在第二个测试中，使用 /debug:full 完成了3个版本的visualstudio。编译时间缩短了一倍 1.52. 在执行完全重建时，编译时间从Visual Studio 2017中的4分39秒减少到Visual Studio 2019 16.8中的3分5秒。对于单个文件更改，观察到缩短了19秒。平均而言，链接时间提高了一倍 18.15倍。 Visual Studio 2019 16.8中的完整重建链接时间 减少10分18秒 ，一个巨大的进步。

编译时间（分钟）	完全重建	单个文件更改
VS2017 15.9.4版/debug:full	4:39	0:55
VS2019 16.7.2版本/debug:full	3:31	0:37
VS2019 16.8版   /debug:full	3:05	0:36
快x倍	1.51	1.53
平均快x倍	1.52

链接时间（分钟）	完全重建	单个文件更改
VS2017 15.9.4版/debug:full	10:53	11:28
VS2019 16.7.2版本/debug:full	1:23	1:39
VS2019 16.8版   /debug:full	0:35	0:39
快x倍	18.66	17.64
平均快x倍	18.15

总时间（分钟）	完全重建	单个文件更改
VS2017 15.9.4版/debug:full	15:32	12:23
VS2019 16.7.2版本/debug:full	4:54	3:40
VS2019 16.8版   /debug:full	3:40	1:15
快x倍	4.24	9.91
平均快x倍	7.07

汽车运动大厦

方法论

在Turn10工作室，Forza赛车队使用MSBuild的结构化日志查看器获取构建和编译时间。以下每一次都是平均4次以上的结果。CL指CL.exe（MSVC编译器），Lib指Lib.exe（Microsoft库管理器）。而Full Build表示总时间，Debug、CL和Lib时间被选择显示；每个时间分别取平均值。

结果

版本15.9 vs 16.7配置文件构建/debug:fastlink

在使用/debug:fastlink，我们可以看到构建时间有了适度的改进，而链接时间提高了一倍 1.96 . Lib时间减少了 9.34倍 .

时间（秒）	完整构建（配置文件）	调试Fastlink	氯	库
VS2017 15.9版	285.5	18	38.9	43.9
VS2019 16.7版	249.75	9.2	40.5	4.7
快x倍	1.14	1.96	0.96	9.34

版本15.9 vs 16.7配置文件构建/debug:fulllink

使用/debug:fulllink，我们可以看到更有利的数字。现在是完整构建时间 1.71倍 更快。同样，链路时间也提高了一倍 4.95 . Lib时间也提高了 10.86倍 .

时间（秒）	完整构建（配置文件）	调试Fulllink	氯	库
VS2017 15.9版	431	172	34	38
VS2019 16.7版	251.75	34.75	34.75	3.5
快x倍	1.71	4.95	0.98	10.86

版本15.9 vs 16.7发布版本

对于发布版本，我们看到了与上面类似的改进。建造时间减少 1.81倍 连接时间提高了一倍 2.44 .

时间（秒）	完整构建（发布）	链接	氯	库
VS2017 15.9版	664	479	30	34.5
VS2019 16.7版	367	196	29	29
快x倍	1.81	2.44	1.03	1.19

分析

重要的构建迭代时间改进是C++团队优化努力的直接结果。在版本16.0和16.2中，链接器的性能提高了 加速程序数据库（PDB）文件生成和类型合并 . 16.6中的算法更改和16.7中更糟情况下的增量链接改进 提高了链接器性能的优化 .  在版本16.8中，多线程生成PDB文件进一步提高了性能。请继续关注一篇技术博客文章，其中详细介绍了16.8的改进。

开发者对话

我们和 安德鲁·塞奇 从操场游戏 （地平线广场4）和 丹特纳 从10号弯开始 （Forza Motorsport）了解改进对他们工作室的影响。

工作室当前是否使用Visual studio 2019？

“我们有VS2017和VS2019的组合，具体取决于设置。大多数工程师已经转移到VS2019的主要项目，但我们仍然有一些工具项目尚未更新，仍在使用2017年

“我们刚刚在2021年1月的最后一周将整个工作室搬到了VisualStudio2019。  我们的一个开发分支在节前就开始运行它了，但几天前它才被广泛采用

您从更快的链接时间中看到了哪些直接好处？

“减少构建和测试变更的迭代时间可以让我们更有效率，尤其是在所有工程师每天多次累积收益的过程中。主要的好处是在切换到完全链接时，使用快速链接进行调试时消除了暂停，因为这将为每个调试会话增加30-45秒，每个构建可以重复多次。”—Andrew

“我看到的最大好处是改进了迭代时间。  即使我们只减少了30秒的链接时间，乘以工作室中的开发人员数量和他们每天编译的次数也会很快变成一个很大的数字

有哪些潜在的长期利益？

“从长远来看，我们还将把所有的自动构建服务器转移到VisualStudio2019，以减少构建验证和测试周转时间。这意味着从签入代码到知道构建已经成功的时间减少了。而且，随着这些构建的持续运行，每个构建的更改也会减少。在未来，将我们所有的工具项目转移到Visual Studio 2019将为工具团队带来更大的生产力优势，并使他们能够花更多时间支持我们的内容创作者。”—Andrew

“长期的好处之一是减少了服务器场的构建时间。  如果有人签入破坏构建的代码，那么我们捕获它的速度越快，所经历的停机时间就越少。  由于开发人员签入新工具代码和构建系统签入新工具二进制文件之间的时间减少，因此它还为我们提供了更快的工具迭代。  此外，还减少了“验证”构建的时间。  在签入之前，每个开发人员构建一个具有代表性的游戏二进制文件示例，以确保它们没有破坏任何东西。  这会减慢迭代的速度（我相信你会看到一种模式正在出现——迭代时间是王道），而我们所能做的任何加快迭代速度的事情都是非常有价值的。”——丹

链接时间的改进如何改变工作室的工作流程模式？

“除了专注于解决问题而不是等待整个团队的构建完成方面的改进之外，我认为我们将能够专注于其他生产力的提高，这些提高在我们的流程中占据更大的比例。例如，即使使用更快的工具集和分布式构建系统，减少代码库中的依赖性也可以提高构建时间，我们将在未来继续集中精力在这一领域。此外，使用完整链接可以减少由暂停引起的精神上的“任务切换”开销，因为当某人遇到暂停时，他们通常会切换到另一个任务一段时间，然后再返回，这可能会导致工作流中断。”—Andrew

“如果我猜的话，我会说我们会看到更少的构建中断。  验证构建需要大量时间才能完成。  即使它们是必需的，有时开发人员会忽略这一步，如果他们在匆忙中，觉得他们的修复是微不足道的，足以安全。  构建时间越快，进入壁垒就越低，人们执行这一步骤的可能性就越大，即使对于他们认为微不足道和/或安全的更改也是如此。  我还认为编译之间的代码更改可能会减少。  编译和链接的时间越长，开发人员在点击按钮编译之前添加的代码就越多。  如果编译和链接几乎是即时的，那么大多数开发人员将使用它作为一种快速的健全性检查，以验证他们刚刚添加的方法/函数/类/等在继续之前是否编译过

下载最新的Visual Studio 2019预览版 为您自己的项目体验更快的端到端构建迭代时间。

这些改进将如何影响您的日常工作流程？请在下面的评论中与我们交谈 推特（@VisualC） ，或通过电子邮件 visualcpp@microsoft.com