VS2019更新:更快的C+工程迭代构建

来源:QQ快报
责任编辑:鲁晓倩
字体:

不变的主题:快,更快,再快

在VS2019的的早期版本,我们曾经对C++工程的链接时间做了一系列的优化,现在,关于性能优化这个话题,我们有更多的信息想和你分享。

在VS2019 v16.7中,我们测试发现,在某些增量链接场景下,链接速度提升了5倍之多,在调试场景下,则观测到了高达1.5倍的完整链接速度提升。在之前的一篇关于《战争机器5》开发团队的一篇文章中,会有关于此信息的更多内容,欢迎观看。

在v16.0和v16.2中进行了链接性能优化之后,我们回顾并重新评估了C++开发者的”编辑-构建-调试”的完整流程。我们考察了诸如3A游戏大作和Chrome之类的大型C++工程,因为这些大型C++工程通常会对工程构建时间十分敏感(想象一下:做一次完整编译需要花上个大半天的时间)。

首先,在VS2019 v16.6中,我们对PDB(Program Database)和DIA(Debug Interface Access)这两个组件中的算法进行了某种优化措施,从而实现调试信息的读取和写入能同

时进行。

其次,在VS2019 v16.7中,我们引入了对最坏情况下的增量编译性能的速度提升,在优化前,它可能比一次完整编译还要慢。

更快的调试信息读取

PDB(Program Database)的构建通常会是连接大型库时的一个性能瓶颈,特别是在极端执行路径下会造成十分漫长的执行时间。而且,PDB信息的读取也会显著地减缓大型工程的调试。特别是当开发者在Visual Studio打开了多个窗口,例如调用堆栈和变量监视,断点触发和单步执行时会看到明显的性能降级。

在我们内部的性能测试中,我们所做的优化对大型工程,例如3A游戏大作等,产生了显著的性能提升,下图可以作为一个例子来参考性能的对比:

虽然,在上图中,时间的绝对值差异来自于我们测试的多个不同工程。但是我们还是可以看到,多个不同的工程编译速度测试都体现了各项操作的性能提升,这些工程并没有进行择优选择,而是一些普遍选择的结果集合。结论就是:

1) 完整编译速度提升达1.5倍

2) 调用堆栈中对不同的函数进行切换速度提升了4倍

3) 初次PDB加载提升了2倍

更加令人信服的一项测试结果是,自从Visual Studio v16.6发布后,单步执行后的断点触发时间较之前快了2倍(平均值)。实际的提升效果取决于你的工程大小和当前打开的调试窗口(例如,监视窗口,调用堆栈等)的数目,但是好消息是,在之前的VS版本中碰到的单步执行缓慢的现象,在v16.6版本中可以明显地感受到我们引入的优化措施。

我们做了什么?

在开发v16.6的时候,我们重点选取了一些典型的开发场景,并找到了优化调试信息读取和写入性能的方法,下面是我们优化算法的一些详细细节:

1. 通过将之前的请求缓存起来,来避免通过RVA(Ralative Virtual Address)来进行查询,因为我们观察到,大概有99%的案例中使用了相同的RVA。

2. 根据需要对类型记录计算旧的CRC32哈希值。(此方法在使用了/Zi编译选项的情况下性能提升最大)

3. 对VS调试器查询模式创建一个快速执行路径。

4. 通过使用AVX指令集优化了memcpy函数,并使用优化后的memcpy来优化内存映射文件的读取过程。

5. 使用C++ strd::sort,而不是qsort。

6. 在整数除法中,使用了一个常量作为被除数(例如页面大小),而不是使用变量。

7. 重用哈希表,而不是每次都重新构建哈希表。

8. 避免虚函数调用,并且对两种最为常见的符号查询过程进行了手动内联优化。

请注意,在上面的第一种情况中,通过将之前的请求缓存起来,极大地优化了PDB的读取。

对最坏情况的优化

增量链接是我们工具中最省时的功能之一。

它允许开发人员在大型项目中进行通用源代码更改时快速进行迭代,方法是重用早期链接的大部分结果,并策略性地应用上次源代码编辑中所做的更改。

但是,它不能容纳所有源代码的更改,有时会被迫退回到完全链接,这意味着总的增量链接时间实际上可能比完全链接差

有意义的是,影响较大的编辑(例如更改编译器或链接器选项或修改被广泛包含的头文件)需要重新构建,但是仅添加新的对象(.obj)文件也将触发完全重新链接。

对于许多开发人员来说,这并不是什么大问题,因为他们很少添加新的目标文件,或者完全链接的时间反正也不会很长。

但是,如果你使用大型二进制文件,或者使用的编码风格或项目系统(例如Unity构建的某些变体)通常会导致添加或删除目标文件,则对增量链接时间的影响可能是数十秒甚至更长。

不幸的是,这些限制对于增量链接的设计至关重要,而删除它们将意味着减慢针对增量链接进行优化的最常见情况:对少量现有编译单元进行简单的源代码编辑。

缓存技术的应用

在v16.7版本中,尽管在更多情况下我们无法合理地进行增量链接,但我们意识到,可以缩短必须完全链接时的链接时间。下面是具体的考虑:

1. 完整链接的大部分时间都花在了生成调试信息上。

2. 与正确链接可执行二进制文件相比,生成正确的调试信息要宽容(容许它出现一些小错误)得多。

在概念上,类似于增量链接的工作方式,我们增加了缓存早期调试信息生成的结果(特别是类型合并的结果)并在后续链接中重复使用的功能。

当增量链接退回到完全链接时,此技术可能意味着链接时间大幅提高(2X-5X)。

下表列出了对三个3A游戏大作和Chrome工程编译产生影响的例子:

但是,使用缓存计算也存在一些缺点:

1. 缓存的数据存储在PDB文件中,因此PDB文件会更大。

2. 由于必须构建缓存,因此增量构建的第一个(干净的)链接会花费更长的时间。

下表列出了对上述工程编译产生的优点和缺点。

“Subsequent full link time”列对应于以下情形:启用了增量链接(/ INCREMENTAL),但必须回退到完全链接,例如引入新的目标文件时。如你所见,如果完整链接时间需要数十秒或几分钟时,此新缓存的影响可能很大。

有趣的是,缓存可用于任何完整链接方案,而不仅仅是增量链接必须回退到完整链接的情况。但是,由于这些缺点,只有在使用增量链接时默认情况下才启用。除非指定了新的/PDBTMCACHE链接器开关,否则发行版本和禁用增量链接(/ INCREMENTAL:NO)的版本都不会受到影响。

同样,/PDBTMCACHE:NO开关可用于禁用高速缓存创建,并根据需要返回到版本v16.6的行为。请注意,链接器不依赖于缓存的存在。如果存在缓存并通过验证,则链接器将使用它来加速链接,但是将忽略丢失的缓存或已失效的缓存。

接下来的工作

我们知道,可能有些人会担心类型合并缓存对PDB大小的影响,因此,将来,我们可能会考虑将缓存放在单独的文件中。 我们没有将其放在增量链接文件(.ilk)中,因为该功能从根本上不与增量链接相关联,这就是为什么要对它们进行独立控制的原因。

后面我们还将继续分享有关v16.8版本中对链接时间改进的一些细节。

总结

所以,总结一下:在最近的VS新版本中,我们改善了PDB文件的读写性能和优化了增量编译失败后的完整编译过程。

你是否有不一样的感受呢?

最后

Microsoft Visual C++团队的博客是我非常喜欢的博客之一,里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙,如果你对Visual C++这门古老的技术还是那么感兴趣,则可以经常去他们那(或者我这)逛逛。

本文来自:《Faster C++ Iteration Builds》

声明:以上内容并不代表本网赞同其观点。如有任何问题,请与不良与违法信息举报中心联系:513175919@qq.com。

www.book1234.com true http://www.book1234.com/q/20210110/20210110A04UXB00.html report 42487
娱乐时尚
  • Vs2019求最大值(c语言设计)1.3例出错,
  • 有懂c语言的大神吗?我用的VS2019,编写一个小程序...
  • Vs2019求最大值(c语言设计1.3例)出错
  • 怎么用vs2019写c语言程序?
  • VS2019的C语言问题,scanf的为什么返回值被忽略了...
  • 怎么在vs2019使用c语言输出之后暂停几秒然后继续输...
  • vs2019对电脑配置要求
  • 小白新人,为什么我用vs2019编程C + +语言,Input...
  • 我的vs2019是这个样子,怎么写c语言啊?
  • 我在VS2019上写了一个C语言项目要用到图片和音频素...
  • 历史文化
    真视界
    旅游美食
    精彩图文
    我爱我车
    母婴健康
    关于本站 | 广告服务 | 手机版 | 商务合作 | 免责申明 | 招聘信息 | 联系我们
    Copyright © 2004-2018 book1234.com All Rights Reserved. 布客网 版权所有
    京ICP备10044368号-1 京公网安备11010802011102号