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

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

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

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

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

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

數(shù)名開發(fā)人員指出Swift仍然處于Beta狀態(tài)，這可能是Swift當前這種行為的***解釋。具體來說，文中提到的毫無必要的釋放/保留調(diào)用暗示了ARC優(yōu)化存在一些Bug，可能不需要積極優(yōu)化就可以修復。

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

原文地址。