游戏大厂说：咱们的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》 返回，检察更多。

本文来源：ror体育-www.nbztfx.com