当你的项目越来越庞大，功能越来越多的同时，也带来了更多的构建时间。最近，VS开发团队向我们透露了有关构建时间优化的一些干货，那么今天我们就来看看，最新版本的VisualStudio中，他们都做了哪些优化措施。
就如本文开头所说的，VS开发团队一直以来都收到来自开发者大量关于构建时间比较长的反馈，道理很容易懂：如果开发者在项目上的构建时间越长，那么他们的很大的一部分时间都是在用于等待构建完成，而不能将时间投入到高价值开发中。VS开发团队一早就意识到，以一种足够快的方式完成项目的构建，可以帮助开发者最大化其生产力。
我们先来看看VS开发团队做的一项对比测试结果，如下图所示：
上图中显示了分别在VS16.2和VS15.9中构建UE4Infiltrator示例工程的时间对比，构建时间以秒为单位，柱子越高表示构建时间越长。我们可以从图中看出，在开启/debug:full选项时，VS16.2的构建时间比VS15.9减少了3.5倍，而当开启/debug:fastlink时，VS16.2也比VS15.9减少了近1.6倍时间。更加值得注意的是，这个时间优化在众多构建时间测试中只是一个中位数。简而言之，同一个大型项目，使用新版本的VS16.2来构建会比使用旧版本VS15.9更快。另外，我们还看到，当使用/debug:fastlink时，从时间上的优化上，看起来效果没有那么大。为什么呢？
关于构建优化的基本原理
在项目的构建阶段，链接是一个比较耗时的过程。在VisualStudio中，链接主要由Link.exe完成。它主要负责将各种各样的大型数据结构塞进最终的可执行文件和调试信息文件PDB中，并且这通常是一个序列化的过程。
早在VS16.0的开发过程中，开发团队就通过减少调试输出的大小和一些对类型哈希的优化策略来对构建时间进行了一定程度的优化。在最新版本中，他们将注意力集中到了优化更加底层的基础数据结构和算法上。通过这次的优化，所有内部数据结构都被更新了，可以更好的提高缓存命中率和减少内存占用，同时优化了一些临时变量的计算来避免在构建阶段的重复计算。
这个优化措施是链接优化的一个重要基础，而它所产生的结果是令人鼓舞的：整个C++生态系统都可以从中获益。
作为一个C++开发者，使用上了最新版本的VS，项目构建不仅可以在/debug:full模式下来的更快，而且在/debug:flastlink模式，甚至在使用/incremental的增量构建模式下，也是同样的快。
同时，开发团队在本次优化中也特别注意了兼容性的维护。所有这些优化都保持了新版本和旧版本库或者旧版本的PDB文件的互操作性，所以兼容性也得到了保证。
让我们来PK一下
开发团队的一个主要目标，还是希望能在大型项目上优化构建时间。这些大型工程，可能是一些大的动态链接库或者EXE执行文件，而这些文件内部也包含了大量的静态库和其他一些组件。开发团队选择了两个最典型的项目：开源项目和游戏。接下来，让我们看看对比测试对比测试结果。
开源项目
首先是一些来自开源社区的大型C++项目，包括Chorme,Clang,MongoDB,MySQL和UE4Game。开发团队对每个项目的构建过程进行研究后发现，链接过程是最耗费时间的。他们分别做了两种不同的统计，一种是在Debug模式下，一种是在Release模式下。在这两种不同模式中，又分别使用了/debug:full和/debug:fast来进行构建测试，并给出如下的对比测试结果。
可以从上图中看到，新版本16.2在/debug:full模式整个构建时间大为减少了。
3A游戏大作
除了开源项目，他们也选取了一些大型游戏项目来参与PK。这些大型游戏都是由大量的组件组合而成，因为XBoxOne的平台支持方面的原因，开发团队和这些游戏的开发商进行了紧密的合作，所以下面的统计数据中，隐去了具体游戏的名词，而以”Beta”和”Charlie”来代替。
我们可以看到，在VS的不同版本中，版本越新，构建时间越短，这个可以看作开发团队在VS版本迭代过程中所付出的辛勤努力一个缩影。
总结
总体来说，开发团队在构建过程中，通过对一些数据结构的优化和各个底层组件的清理，在/debug:fastlink和/incremental模式下，构建的时间比之前减少了至少2倍，而在/debug:full模式下，可以减少3到6倍。而且，在构建时间减少的情况下，生成的二进制文件也保持了全面的兼容性。
在接下来的时间里，开发团队也坦承：”我们还将继续努力工作，因为还有一些其他值得优化的地方”。
所以，让我们拭目以待吧。
感谢阅读，本文来自VisualStudio博客。