前言
Swift是一门非常优秀的语言。由于没有历史包袱，Swift得以集众家之长，甚至可以说激进。默认非空，类型安全，严格的编译时检查，为开发者避免了许多的坑。而强大的类型推断，面向协议的设计，以及函数式支持，使得写代码成为一种非常愉悦的体验。
当然，作为一门只有4年历史的语言，Swift仍然有许多亟需改进的地方。对于大一些的项目，日常开发中经常会遇到代码高亮失效，代码提示失效的问题，好好的一个IDE活生生变成了文本编辑器。而论项目编译时间，Swift项目的编译速度通常是OC的3倍。这让用iMac（8G内存，笔记本机械硬盘）的笔者养成了经常盯着屏幕发呆的习惯。
实际上，在Swift普及率较高的欧美开发者当中，也有人表示，对于大一些的项目，宁肯用OC。不是Swift语言不好，实在是XCode太坑（当然主要是swiftc这个前端的锅）。好在，Swift团队的一些成员正在重点改进编译相关问题，目前的测试数据似乎不错。预计到XCode10实装的时候，能够明显改进项目的编译速度，IDE变白板的情况也会改善很多。
正文
在那之前，官方提供了一个工具，可以方便定位会产生编译瓶颈的代码。具体做法如下（XCode 8 以上）：
- 在项目的target中，打开build setttings
- 在里面找到
Other Swift Flags这一项 - 添加两个参数：
-Xfrontend和-warn-long-function-bodies=100，这里100单位是毫秒 - 重新编译项目
以上的设置，会在编译耗时过长的函数方法上产生一个警告：
Instance method 'updateCurrentTime()' took 6228ms to type-check (limit: 100ms)
没错，6秒钟，而且只是类型检查。对于类型检查来说，100ms已经是很大的数字了，大部分情况下，1ms左右才是合理的。
简单说一下Swift代码编译过程：
Parsing: 执行语法检查，生成AST语法树，返回IDE语法错误及警告
Semantic analysis: 语义分析，执行类型检查及类型推断，生成类型完整的AST，返回IDE语义错误及警告。
Clang importer、SIL generation等等。。。
编译过程的前两步，直接决定了语法高亮和代码提示的响应速度。这个过程里Swift与OC最大的不同，便是引入了类型推断。实际上个人以为类型推断是Swift能够拥有简洁优雅语法的核心要素之一。想当年C++没有auto的时候，用Vector之类的容器真是让人欲仙欲死。
真是成也类型推断，败也类型推断。
我们来看看有问题的代码：
// _lastTime和currentTime都是Double类型的属性
guard abs(Int(round(_lastTime)) - Int(round(currentTime))) > 0 else {
return
}
其中abs()和round()是对应C函数的泛型重载，Int()是参数重载，-和>是运算符重载。
看来复杂表达式中有了过多泛型和重载之后，类型推断的性能会指数级的下降，随之而来的便是类型检查时间过长。
因此，作为应对手段，我们只能把代码拆开：
let iLast: Int = Int(round(_lastTime))
let iCurr: Int = Int(round(currentTime))
let diff: Int = abs(iLast - iCurr)
guard diff > 0 else { return }
于是警告消失了，通过拆分表达式和显示类型提示，这段代码的类型检查速度提高了至少60倍。也由于这是代码编译过程的一部分，每次重编译代码都节省了5秒钟的人生。
这是一个悲伤的故事。
上面的例子可能比较特殊，不过除了重载以外，尾随闭包也是类型推断的重灾区。比如下面的代码：
// 250ms type-check
let averageScore = Int(round(scoreResult
.map{Float($0.value)}
.reduce(0, +)
/ Float(scoreResult.count)))
还是拆代码，以及闭包的显式类型提示：
// 10ms 以内
let ast: Float = scoreResult
.map{r in return Float(r.value)}
.reduce(0, +)
/ Float(scoreResult.count)
let averageScore: Int = Int(round(ast))
这么把警告一个个干掉之后，虽然不可能完全解决问题，但是满屏黑白的情况会减少很多，至少不用经常习惯性的按⌘S来刷新了。（没错，除了代码键入，保存也能触发语法检查）
后记
在官方对于swift编译性能改进的分析中(链接)，提到了一些改进方向：
- 增量编译模型过于保守，许多不必要的重新编译。
- 名字解析过于激进，读入(反序列化)了过多的定义。
- 前端任务的二次方级（复杂度）的任务中，很多引用的定义的类型检查不够lazy。
- 表达式的类型推断对于约束的推导没有效率，某些情况下（时间复杂度）是超线性甚至指数级的。
- SIL优化的分析过程有时会缓存失败，导致超线性的性能退化。
- SIL生成IR的过程，在某些情况下（比如大的值类型）会生成过多的IR码，影响后端LLVM的处理时间。
由此，我们可以期待，在Swift 5发布的时候，无论是IDE的性能，还是代码编译速度，都有一个明显的改善。
PS：Swift 5还可以期待async/await和Ownership这样的并发及运行时性能改进，以及官方的主要目标，ABI稳定（跨版本二进制兼容的一部分）。