Appleの新プログラム言語であるSwiftについて，OS XおよびiOS開発者に提供するメリットのひとつとして同社が主張するのは，そのパフォーマンスだ。しかしながら，社外の開発者による初めてのテストとベンチマークは，いくつかのケースにおけるSwiftのパフォーマンスが，まだ満足のいくものでないことを示している。
開発者であるJukka Suomela氏がStack Overflowに寄せた記事によると，氏はあるアルゴリズムをSwiftで実装したときに，パフォーマンスが極端に劣ってることに気が付いたという。その分析を進めていくうちに氏は，自身の記述したコードの中に，配列のソートのような単純なタスクに起因する，大きなボトルネックが存在することを発見した。
実際に100万個のランダムな整数配列をソートした場合，Swiftを使用すると6秒を要するのに対して，C++を使えば0.06秒，Pythonでは0.6秒だった。これらの結果はXcodeのリリースビルドで一般的に使用される，最適化レベル-O3でコンパイルした結果から得られたものだ。Xcodeのデバッグで使用される-O0 フラグに相当する，コンパイラの最適化をすべて無効にした場合には，上記のテストは88秒だった，と氏は報告している。
氏のこの結果は，Stack Overflowでの議論に参加した他の開発者によっても確認された。開発者のsjeohpはクイックソートアルゴリズムを実装して，-Ononeを指定してコンパイラ最適化を無効にした場合，SwiftがCよりもおよそ1,000倍遅いことを確認している。その一方で氏は，積極的な最適化の実施(-Ofast0をコンパイラに実行させた場合，SwiftはCよりもわずかに速いことを発見した。イメージ処理テストに関するStack Overflowへの２回目の記事でも，同じような発見が報告されている。
LLVMの資料によると，積極的な最適化を有効にした場合には，標準への準拠は厳格に遵守されない。-Ofastはすべての-O3最適化に加えて，数学関数に対するIEEEあるいはISO仕様を緩和する-ffast-mathを有効にする。したがってこの仕様を保証する必要のあるプログラムでは，処理の結果が不正確になる可能性がある。さらに-Ofastは，整数値のオーバーフローと配列のインデックスオーバーフローのチェックを無効にするため，Swiftの安全機能を縮退させることにもなるのだ。
分析をさらに続けたJukka Suomela氏が別のテストでコンパイラの生成するアセンブリコードを調査したところ，配列に対する単純なループにおいて，まったく不要な大量のメモリ管理(retainとrelease)コールを生成されていることを発見した。このテストでは数学的な処理は行っていないので，パフォーマンスのボトルネックは主としてこれらの不要な処理に起因するようだ。
何人かの開発者が指摘しているように，Swiftはまだベータ版である。今回の件は，Swiftプログラムの現時点での動作であると理解すれば十分だろう。特に指摘されたような不要なrelease/retainコールについては，ARCオプティマイザのバグを示唆するものであって，積極的な最適化作業を必要とせずにフィックス可能なはずだ。
Swift言語はベータ版であるため，Swiftを使って開発したアプリをレビュー用に提出することは許可されていない。最終的なXcodeのリリース今年秋に予定されている。