分析Swift項目的編譯時間

本文翻譯自：Profiling your Swift compilation times

我遇到一個問題。我正在開發的一個全新的應用－是100%用Swift來寫的。考慮到這個項目只有大概200個文件，我注意到它須要的編譯時間超過了個人想象，更重要的是，它比前幾個星期的編譯速度慢了不少。在這個問題變得愈來愈糟糕以前，我須要儘快找到問題的根源。

第一步是添加 -Xfrontend -debug-time-function-bodies 這個Swift 編譯選項：

這會讓這個編譯器輸出一個函數編譯的時長（感謝Kevin Ballard 給我這個線索）。這個編譯日誌能夠在Xcode 的 Report 窗口中看到，但須要你手動一個個展開每一個文件：

下一步爲了理解它們，須要把全部這些日誌聚合在一個文件。

咱們使用 xcodebuild 命令工具來把全部的日誌輸出到控制檯：

# Clean and build, capturing only lines containing `X.Yms` where X > 0, sorting from largest to smallest
xcodebuild -workspace App.xcworkspace -scheme App clean build | grep [1-9].[0-9]ms | sort -nr > culprits.txt

接下來就是在這些輸出中找到我想要的信息。我發現有超過1200行的數據是編譯超過3秒的，謝天謝地的是這麼多行都是三個相同的函數重複不少次（我對編譯器不是很懂，不明白爲何會出現這種狀況，可是輸出的數據中包含了「closure」閉包這個關鍵詞仍是提供了一些線索）

3158.2ms    /Users/Bryan/Projects/App/FileA.swift:23:14 @objc get {}
3157.8ms    /Users/Bryan/Projects/App/FileA.swift:23:52 (closure)
3142.1ms    /Users/Bryan/Projects/App/FileA.swift:23:14 @objc get {}
3141.6ms    /Users/Bryan/Projects/App/FileA.swift:23:52 (closure)
3139.2ms    /Users/Bryan/Projects/App/FileA.swift:23:14 @objc get {}
3138.7ms    /Users/Bryan/Projects/App/FileA.swift:23:52 (closure)
3128.3ms    /Users/Bryan/Projects/App/FileB.swift:27:22 final get {}
3109.9ms    /Users/Bryan/Projects/App/FileA.swift:23:52 (closure)
3052.7ms    /Users/Bryan/Projects/App/FileA.swift:23:14 @objc get {}
3052.6ms    /Users/Bryan/Projects/App/FileA.swift:23:14 @objc get {}
3052.2ms    /Users/Bryan/Projects/App/FileA.swift:23:52 (closure)
3052.1ms    /Users/Bryan/Projects/App/FileA.swift:23:52 (closure)
3049.0ms    /Users/Bryan/Projects/App/FileB.swift:27:22 final get {}
3026.1ms    /Users/Bryan/Projects/App/FileB.swift:27:22 final get {}

更瘋狂的是，全部這三個函數都是一行簡單的代碼。重寫這三行代碼就可讓個人項目編譯時間快60%。我知道這不少人不爽，可是老實說，我很是高興弄清楚了到底是什麼緣由，若是下次遇到一樣的問題，我知道本身該怎麼作了。

你可能想知道這個三行代碼是什麼。這三行代碼都很是類似，相似下面的：

return [CustomType()] + array.map(CustomType.init) + [CustomType()]

我不能肯定形成這個問題是由於數組的 append 操做，或者mapping 操做，仍是二者的結合。我放棄使用這些函數，不理會是否影響性能，添加了額外的臨時變量和可變參數，用普通的方式改寫。我不是第一個發現這個數組添加的操做很慢，就由於這樣一行優雅，看似無害的代碼讓我親身經歷了這個痛苦。

Swift 仍然是一個很是年輕的語言，有這樣的問題很正常，做爲一個開放的社區，咱們應該互相幫助，防止另外一個痛苦發生。