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

發表於2014-06-16

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

相關文章