自從Swift誕生以后，蘋果就一直在努力讓它變得更好，更快。相比更加靈活的Objective-C，Swift顯得更加老實本分。但是，如果你真的對它了解之后，你會覺得原來有如此之大的威力。
開發(fā)語言離不開編譯器的支持，蘋果的編譯器團隊一直在優(yōu)化他們。但是在開發(fā)過程當中，我們往往沒有把編譯器的作用發(fā)揮到極致，主要原因就是我們并不是太明白編譯器是如何為我們工作的。
Whole Module Optimizations
這是一個我們應(yīng)該好好利用的特性，使用很簡單，如下圖開啟：
有了whole module optimization這一特性，編譯器對你的代碼進行分析的時候，再也不會局限于一個文件當中了，而是整個module。有什么用呢，有了這一特性，編譯器可以對你的代碼了解得更多，能更好的做好編譯工作。比如下面這個例子：
1.swift:
func foo() {
let x: Int = ...
let y: Int = ...
let r = min(x, y)
...
}
2.swift:
func min<T : Comparable>(x: T, y: T) -> T {
return y < x ? y : x
}
這是一個比較簡單的泛型例子，目的在于比較x和y的大小，然而由于分別位于不同的源文件中，如果沒有Whole Modulw Optimization的話，編譯器會生成如下的代碼。
func min<T : Comparable>(x: T, y: T, FTable: FunctionTable) -> T {
let xCopy = FTable.copy(x)
let yCopy = FTable.copy(y)
let m = FTable.lessThan(yCopy, xCopy) ? y : x
FTable.release(x)
FTable.release(y)
return m
}
為什么會這樣呢，因為編譯器沒有辦法得到足夠的信息去推斷參數(shù)的類型，x和y可能是一個Int、Float等等Value Type從而不需要考慮引用計數(shù)，但是它又或者是引用類型需要考慮引用計數(shù)呢？
所以，當有了這一特性之后，編譯器的“視野”再也不受限于單個文件了，它能得到足夠的信息，知道x和y是一個Int，那么最終優(yōu)化出來的代碼便會是下面這個樣子：
func min<Int>(x: Int, y: Int) -> Int {
return y < x ? y : x
}
除了在泛型當中進行類型推斷，還有Dynamic Dispatch我們也可以給編譯器足夠的信息，讓它為我們生成最優(yōu)的代碼, 比如下面的例子：
父類Pet：
public class Pet {
func noise() ...
var name: String
func noiseImpl() ...
}
子類Dog：
class Dog {
...
override func noise() ...
}
然后有下面一個function：
func makeNoise(p: Pet) {
print("My name is \(p.name)")
p.noise()
}
編譯器會生成這樣的代碼：
func makeNoise(p: Pet) {
let nameGetter = Pet.nameGetter(p)
print("My name is \(nameGetter(p))")
let noiseMethod = Pet.noiseMethod(p)
noiseMethod(p)
}
原因在于編譯器并不知道父類中的屬性等有沒有被子類重載，所以需要去動態(tài)的查找它的getter。如果我們在開發(fā)的之后已經(jīng)知道子類不需要去修改name，那么編譯器會生成下面這樣的代碼:
...
print("My name is \(p.name)")
...
你所需要做的就是給name前面加上一個final關(guān)鍵字。
對于不會被子類重載的function，你也應(yīng)該加上private，這樣子編譯器也不會去進行一些無謂的檢查工作，這都將加讓你的代碼運行得更加迅速。
同時，為什么說Swift會比OC快，從這兒我想大家也能明白了吧。在OC當中，每個函數(shù)調(diào)用，最終都會變成objc_msgSend的形式，依靠runtime進行消息派發(fā)。這里會存在兩個主要的問題，一個是數(shù)據(jù)的類型只能在運行的時候才能真正的確定下來，這樣帶來了安全隱患；同時，由于動態(tài)派發(fā)，速度也將會大打折扣，所以還在使用OC的朋友，是不是可以考慮下使用Swift了呢？
