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

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

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

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

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

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

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

因?yàn)樵撜Z(yǔ)言仍處于Beta狀態(tài)，蘋(píng)果不會(huì)允許開(kāi)發(fā)者提交Swift開(kāi)發(fā)的應(yīng)用進(jìn)行審查。Xcode的最終版本預(yù)計(jì)在今年秋天發(fā)布。

原文地址。