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

效能是蘋果聲稱新程式設計語言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的最終版本預計在今年秋天發布。

原文地址。