评测 Swift 3.0 项目编译优化选项对编译速度的影响

昨天看了 Swift 官方发出的这篇《Whole-Module Optimization in Swift 3》，了解了一些 Whole-Module Optimization 的原理。

简单地说，Whole-Module Optimization（全模块优化，以下简称 WMO），即在编译项目时，将同属于一个 Module（可以理解为一个 Target、一个 Package）的所有源代码都串起来，进行整体的一个分析与优化，区别于 Single-File Optimization（单文件优化，以下简称 SFO），WMO 可以更好的统筹全局，去 inline 函数调用、排除死函数（即写了却从不调用的函数）等等，大幅优化最终目标文件，使性能提升 2~5 倍。

我对性能的提升没有疑议，但对其中提到的「编译时间（Compile Time）」的优化产生好奇。既优化性能，也同时减少编译时间？于是我做了一个实验了解了不同的编译器优化选项的不同效果。

实验：测试 Optimization Level 在 None（不优化）、SFO、WMO 下分别对编译速度的影响

实验对象：基于 Swift 3 的奇点 for 微博，约 24,000 行代码

实验方式：在 Debug 模式下分别选择一档优化，编译测试时间。

Xcode 配置：

显示编译时间： defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES

测试结果：

None 模式（平均 102 秒）：

• 97.985s
• 106.039s
• 104.387s

SFO 模式（平均 122 秒）：

• 116.114s
• 123.749s
• 126.554s

WMO 模式（平均 89 秒）：

• 91.433s
• 87.440s
• 88.465s

可以看到，虽然 WMO 模式是带优化的，但是它编译速度确实比不优化的 None 模式还要快，快了 13 秒，接近 15%。而 SFO 显然最慢，比 None 不优化要慢近 20%。看到这里，官方说的没错，WMO 是既优化了性能、又优化了编译速度的模式，这也是它在新的 Xcode 中成为默认选项的原因。

但是不要高兴的太早了，WMO 只是在 Release 模式下成为了默认且推荐的选项，在 Debug 模式下默认依然是 None。那我能不能在 Debug 模式也把优化模式改成 WHO 呢？根据我的测试：能，但最好不要。因为 WMO 没有把增量编译优化好，在我的项目里，无论是我是改了一个没被多方引用的文件的私有函数，还是改了一个被其他文件引用的公开函数，增量编译都没能工作——编译器老老实实地把所有的文件再编译了一遍，而在 None 和 SFO 下，这些更改带来的增量编译通常能在十余秒或更快完成。

在日常开发中，显然你是不能忍受每次做个小改动然后去测试的时候就要经历漫长等候的，我想这也正是 Xcode 默认没把 Debug 模式也开启 WMO 的原因。

然而，尽管 Xcode 给 Release 模式开启了 WMO，但事实上我们并不会有太大体验，一来 Release 是很少频次的动作，二来平常我们通过 Archive 来发版本，不仅仅会进行标准的 Release build，还会增加一个 Bitcode 的动作（如果项目开启这个的话），这一切也都使 Archive 整个动作非常慢，WMO 模式减少的编译时间微乎其微。

但是，无论怎样，如果你的项目是 Swift 3，Release 下 WMO 没有开启的话，那就一定要去开启，这影响的不仅仅是编译时间，还有最终目标的运行性能。

图为开启 WMO 后编译目标，只有一个 Compile sources files 的步骤，展开后也没有一个一个文件的 Compile：

不知道你们的项目在开启 WMO 后编译速度提升了多少？