Swift并不像蘋果說的那么快：第一次基準測試

　　英文原文：Swift Might Not Be As Fast As Apple Claims It To Be: First Benchmarks

　　性能是蘋果聲稱新編程語言 Swift 將帶給 OS X 和 iOS 開發人員的好處之一。然而，由獨立開發者執行的第一次實驗和基準測試顯示，Swift 在某些場景的性能并不如人意。

　　開發人員 Jukka Suomela 在 Stack Overflow 發表了一篇帖子說明他的發現。當用 Swift 實現一個算法時，他注意到其性能非常差。深入分析后，Jukka 最終發現代碼的主要瓶頸來自一個數組排序這樣的簡單任務。

　　事實上，Swift 對 100 萬個隨機整數的數組進行排序，需要耗時 6 秒，而 C++ 只用了 0.06 秒，Python 為 0.6 秒。這些測試使用的是-O3 編譯優化級別，這是 Xcode 發布構建時常用的級別。Jukka 說，如果禁用所有編譯優化，即對應于 Xcode 調試構建的-O0，上述測試用了 88 秒。

　　Stack Overflow 上回復該帖的其他開發人員證實了 Jukka 的發現。開發人員 sjeohp 用 Swift 實現快速排序算法時，發現如果不啟用編譯優化（-Onone）會比C慢 1000 倍。另一方面，他發現當強制積極的編譯優化（-Ofast）時，Swift 比C稍快。Stack Overflow 的另一個帖子描述了圖像處理測試，也強調了類似的研究結果。

　　根據 LLVM 文檔，積極優化忽略了嚴謹的標準規范。-Ofast 啟用了所有-O3 優化并開啟了-ffast-math，后者放寬了 IEEE 或 ISO 的數學函數規范，可能導致那些應該具有規范保證的程序產生不正確的輸出。此外，-Ofast 禁用了整型溢出和數組下標越界的檢查，因此降低了 Swift 的安全特性。

　　Jukka 進行了深入分析，他在編譯器對另一個測試所生成的匯編代碼中，發現一個數組的簡單循環產生了大量的內存管理調用（保留和釋放），而這是完全沒有必要的。這個測試沒有涉及數學，因此主要的性能瓶頸似乎來自這些無用的調用。

　　數名開發人員指出Swift 仍然處于 Beta 狀態，這可能是 Swift 當前這種行為的最好解釋。具體來說，文中提到的毫無必要的釋放/保留調用暗示了 ARC 優化存在一些 Bug，可能不需要積極優化就可以修復。

　　因為該語言仍處于 Beta 狀態，蘋果不會允許開發者提交 Swift 開發的應用進行審查。Xcode 的最終版本預計在今年秋天發布。