性能提升 Visual Studio 2017 性能提升和建议

Blogs.msdn.microsoft.com/c/2018/01/26/visual-studio-2017-绩效改进和建议/

随着C++项目的发展和优化器复杂度的增加，编译器的编译时间或性能逐渐成为关注的焦点。这是我们Visual C++团队非常关注的一个问题，也成为了15.5版本和以后工作的重点。我想花几分钟时间总结一下我们最近为提高性能所做的特殊更改，并为您提供一些提高编译项目性能的建议。

需要注意的是，并不是所有的改变都能提高所有场景的性能。将编译时间减少到期望值是一项长期任务。最近开始用AAA游戏作为标杆。未来还需要更多的努力。

VS工具集有三个部分需要单独改进。首先是编译器前端，也就是c1xx.dll的执行。这是一个工具，它以cpp文件为输入，生成一种独立于中间语言的语言，或者说IL，将输入到编译器的后端。编译器后端也叫c2.dll。它从前端读取IL，并从中生成包含真实机器代码的obj。最后，链接器将读取后端编译器生成的各种obj和lib，并将它们组合起来生成最终的二进制文件。

编译器前端性能

在很多项目中，前端编译时间阻碍了整体性能的提高。幸运的是，它可以通过直接向msbuild或其他编译系统添加/MP选项(该选项可以使cl.exe同时处理多个文件)，甚至通过分布式机器使用像incredibuild这样的工具来加速。提高性能的第一步是在编译项目时高效地分布和并行化。

第二步是确保您有效地使用PCH文件。PCH文件基本上是cl.exe完全解析。h文件——解决了每次做这个的麻烦。你会被它的功能震惊。一旦头文件(如windows.h或某些DirectX头文件)被完全预处理，它就会变得非常大，往往成为后处理源文件中最重要的部分。PCH文件将开启一个新世界。这里的主要操作是只包含经常更改的文件，这确保了PCH将帮助您提高很多性能。

最后一个建议是限制#include的使用。包含PCH文件以外的文件是一项非常昂贵的操作，需要搜索包含路径中的每个文件夹。很多文件的I/O操作，这是一个每次都要重复的传递操作。这就是为什么PCH将扮演重要角色。在微软内部，有很多关于“只包含你想用的文件”的成功案例。/showInclude选项可以让您意识到包含文件的成本有多高，并可以指导您只包含您需要的内容。

最后，我想让你知道/Bt选项。该选项可以显示每个文件的前端编译时间(也包括后端和链接时间)。它可以帮助你找出性能低的原因，让你知道哪些文件需要你花时间优化。

以下是我们为提高前端性能所做的更改。

刷新PGO计数

PGO，或者说是profile optimization，是一种编译器后端技术，在微软应用广泛。基本原理是你生成一个产品的特殊测试版本，通过运行测试用例生成配置文件，根据收集到的数据重新编译/优化。

我们发现在编译或优化前端二进制文件(c1xx.dll)时使用了旧的配置文件数据。当我们重新检查或重新收集PGO数据时，我们将看到10%的性能提升。

我们在这里学到的是，如果使用PGO来提高产品的性能，请确保定期收集经过培训的数据。

删除_假设的使用

_假设(0)向编译器后端发送一个信号，表明特定的代码路径(可能是默认标签，等等。)无法联系到。很多产品会把它包含在一个宏中，命名为类似于UNTACHED的东西，然后执行它，这样调试版本会声明这个信号，发货版本会把这个信号传递给编译器。编译器会做一些操作，比如移除分支或者转移目标声明。

这个说得通。如果在运行时实际上可以到达一个_假定(0)声明，那么结果就是一个错误代码。这将在许多不同的情况下带来许多问题(有些人抱怨这将导致安全问题)-所以我们做了一个实验，看看通过重新定义一个宏来简单地移除all _假定(0)的影响。如果回归较小，为了不引起其他问题，可能不值得放在产品中。

令我们惊讶的是，删除_假设声明将前端性能提高了1%-2%。做决定很容易。这种现象的根源是，虽然_假设在许多情况下是对应于优化器的有效信号，但它实际上可能会阻碍其他优化(尤其是较新的优化)。我们将在未来的版本中继续改进假设。

改进winmd文件加载

我们在winmd文件加载上做了很多改动，旨在提高10%的加载性能(此项约占总编译时间的1%)。这只会影响到UWP项目。

编译器后端

编译器后端包含一个优化器。性能问题有两个层次，“正常”问题(我们在这里做了很多工作，希望提高1-2%)和“长期”问题。有一种特殊的方法会导致一些优化达到不合理的路径，需要30s或更长的时间来编译——但大多数人不受影响。我们关心这一点，并不断改进。

如果使用/Bt选项，看到一个异常的文件需要异常的时间进行后端编译，那么下一步就是在编译时使用/d2cgsummary选项。Cgsummary(或代码生成汇总)会告诉你哪个函数耗时长。如果此功能不在您的关键性能路径中，这意味着您很幸运，那么您可以通过以下方式关闭此功能的优化:

#pragma优化("，"关闭)

void foo() {

...

}

#pragma优化("，"开)

那么这个功能就不会优化。请与我们保持联系，我们可以帮助您解决这个问题。

除了对编译时间异常的方法关闭优化，我还需要提醒大家在使用_forceinline的时候要小心。通常，客户会使用forceinline让inliner做他们想做的事情。这种情况下，我的建议是尽量有针对性的使用。编译器后端非常重视_forceinline。它免除了所有行内预算检查(forceinline的成本不会对行内预算造成损害)。这些年来，我们看到了很多案例，以代码质量为由任意使用_forceinline是刷新性能的主要障碍。基本上，与其他编译器不同，我们经常通过在前端内联IL来进行预优化。有时候这样做是有利的。我们对不同的内容进行不同的优化，但是一个缺点是我们将无法恢复大量的工作。如果你有一个很深的内嵌树，它很快就会变得不可控。这就是为什么在像Tensorflow/libna这样的地方编译时间太长的原因。这就是我们未来版本将致力于改进的地方。

使用LTCG构建时理解iLTCG。增量LTCC是一种新技术，通过它我们只需要为LTCG构建中改变的函数(以及这个函数所依赖的函数，比如它的内联函数)生成代码。没有它，即使只做了很少的改动，整个二进制文件都会被重新编码。如果您已经放弃使用LTCG，因为它让您陷入了内部开发周期，请了解iLTCG。

最后一个建议也更适用于LTCG构建(这里只有link.exe单独做代码生成，而不是分布式的cl.exe)，所以考虑使用/cgtreats #来适应默认的核心扩展策略。正如您将在下面看到的，为了更好地测量，我们做了一些更改，但是默认情况下仍然使用4个内核。未来我们会重点增加默认核心数，甚至灵活应用机器的核心数。

下面是我们最近为编译器后端做的一些免费的性能改进:

内联读缓存

一些编译器通过将所有优化的内联函数保存在内存中来实现内联。此时内联的执行是内存复制到当前函数指定位置的问题。

但是在VC++中，我们在内联的操作上有一些不同。我们实际上是从磁盘上重新读取未优化的版本。这显然会慢一些，但同时可以减少内存的使用。在性能改进的问题上，这将是一个障碍，特别是对于一个大量使用_forceinline的项目。

为了平衡内存和性能问题，与其他编译器相比，我们在内存问题上做了一些小的改动。由于内联操作，编译器后端在方法被读取固定次数后缓存该方法。实验表明，当次数N=100时，内存和性能问题可以得到很好的平衡。我们可以将参数/d2FuncCache#传递给编译器(或者在LTCG

在生成过程中将参数/de:-FuncCache传递给链接器。0表示不缓存，50表示当内联执行50次时缓存。

类型系统编译推广

本项目适用于LTCG大厦。在LTCG构建之初，后端将致力于编译各种优化模型，用于所有类型的程序，如虚拟化。这很慢，而且会占用大量内存。过去，当类型系统有问题时，我们建议人们通过将/d2:-noteypeopt传递给链接器来禁用它。最近，我们做了很多改变来平衡类型系统的这个问题。事实上，这种变化是非常基本的，它涉及到我们如何执行位集操作。

更好地扩展到多核

后端是多线程的。但也有许多限制:我们从下到上执行编译指令——这意味着一个方法无论被调用多少次都只编译一次。这是一个函数。如果把收集到的信息用在被调用函数的编译过程中，可以更好的优化。

还有一个限制:如果上面的方法有一定的规模，可以省去，不需要应用自下而上的信息就可以直接开始编译。这样单线程编译就不会遇到瓶颈，因为会丢失少量剩余的大型方法，由于依赖树较深，无法立即启动。

我们重新评估了大容量功能的局限性，并明显降低了这一局限性。在这个变化中，我们不评估任何明显的代码质量损失，但是这一次性能的提高将在很大程度上取决于项目之前被大容量方法限制了多少。

其他在线促销

内联时，我们对符号表的构造和合并进行了修改。这一变化提供了一个全面的附加小好处。

更好的块粒度锁操作

像大多数项目一样，我们不断地配置和检查锁操作的限制。因此，在少数情况下，我们提高了锁的锁定粒度，特别是如何映射和获取IL文件，以及符号是否相互映射。

符号表和符号映射的新数据结构

在LTCG，要在模块中准确绘制符号需要做大量的工作。我们用新的数据结构重写了这部分代码，并带来了改进。这对于整个类型特别有帮助，通常是游戏行业，这些项目中的传说的映射操作会很大。

LTCG多线程的其他部分

编译器后端是多线程的，这只是相对正确的说法。我们只讲后端代码生成，抛开主要工作。

然而，LTCC的建筑要复杂得多。它还包含一些其他部分。最近，我们以放弃LTCC大楼10%的速度提升为代价，将其他部分制成多线程。这项工作将在未来的版本中继续。

连接器的改进

如果您使用LTCG(您应该使用它)，您可能会看到链接器是您的编译系统的一个障碍。这是不公平的，因为链接器只在LTCG使用c2.dll进行代码生成——所以上述所有建议都适用。但是除了代码生成之外，链接器还有其传统的工作要做，即解析引用并将所有obj生成最终的二进制文件。

您在这里可以做的最重要的事情是使用fastlink。Fastlink实际上是一种新的PDB格式，由/debug:fastlink选项使用。当链接时，这将大大减少生成PDB所需的工作。

在调试版本中，您应该使用/incremental。增量链接允许链接器只更新已更改的obj，而不是重建整个二进制文件。当您在内部循环中做了一些更改，需要重新编译链接测试并重复这些步骤时，增量链接会有很大的不同。类似于fastlink，我们在这方面做了很多稳定的改进。如果你以前用过，但是发现不稳定，请再试一次。

以下是编译器性能改进的最新变化:

新的ICF启发式

ICF折叠是接头的主要障碍之一。这是将任何相同的函数折叠在一起以保存空的阶段，也是将这些函数的引用重定向到单个实例的阶段。

这个版本对ICF做了一点改动。综上所述，通过依靠一个健壮的哈希函数来做等价而不是使用memcmp。这显然会加快ICF的速度。

回到64位链接器

对于大型项目，32位链接器存在地址空的问题。它经常通过获取文件来映射内存中的文件。如果文件很大，相邻地址之间的内存映射空将是不可能的。作为替代，链接器退回到较慢的缓存输入/输出路径，在那里链接器只读取它需要的一些文件。

链接器知道，与内存映射输入/输出相比，缓存输入/输出代码路径非常非常慢..于是我们加入了新的逻辑。是的，32位链接器在返回缓存I/O之前，会以64位进程的形式重新启动自己。

Fastlink改进

/debug:fastlink在一定程度上是一个新特性，可以明显加快调试信息的生成，这一步是所有链接做法的主要部分。我们建议每个人都专攻这个选项，并尽可能使用它。在这个版本中，我们加强和加速了这个选项，并投入更多的时间和金钱来编写这个选项，以便在以后的版本中进行改进。如果你刚开始用，但是因为使用体验不好而停用了，请再试一次。我们在15.6版本中对这个选项做了更多的改进。

增量连接的回滚

我们听到了关于增量链接的抱怨，说有时增量链接比整体链接慢，这取决于有多少obj和lib被更改。目前我们很努力想搞清楚这个情况，会直接转到整个环节。

结论

以上列表并不详尽，但却很好的总结了VS在过去几个月中显著的性能提升变化。如果你曾经被编译链接VC++的时间太长困扰过，建议你再试试15.5的工具集。如果一个项目的编译时间与其他类似规模的项目相比，或者与其他工具相比，长得不合理，我们愿意帮你看看。

请记住，cl.exe可以添加/d2cgsummary，link.exe可以添加/d2:-cgsummary，这两种方法可以帮助您找出生成代码时的性能问题。这包括上面讨论的内联读取缓存的问题。遇到大项目记得加/Bt，可以帮你搞清楚每个文件的前端和后端编译时间和链接时间。/time+可以显示链接时间，包括ICF使用的时间。