Swiftによるメモリ使用量とパフォーマンスの向上

Swiftによるメモリ使用量とパフォーマンスの向上

Swiftコードのパフォーマンスとメモリ管理を向上させる方法を学びましょう。アルゴリズムの全体的な変更から、新しいInlineArrayおよびSpanタイプによるメモリと割り当ての詳細な制御まで、既存のコードをブラッシュアップする方法について説明します。

関連する章
- 0:00 - イントロダクションとアジェンダ
- 1:19 - QOIフォーマット＆パーサアプリ
- 2:25 - アルゴリズム
- 8:17 - 割り当て
- 16:30 - 排他性
- 19:12 - スタック vs ヒープ
- 21:08 - 参照カウント
- 29:52 - Swiftバイナリ解析ライブラリ
- 31:03 - 次のステップ
リソース
関連ビデオ

WWDC25
WWDC24
- Swiftのパフォーマンスの詳細
こんにちは Swift Standard Library担当の Nate Cookです本日はコードのパフォーマンスを確認して改善する方法を説明するとともに Swift 6.2とその標準ライブラリに追加された新機能を紹介します新しいInlineArray型とSpan型を実際に使用して値ジェネリクスを試しエスケープ不可の型について学びましょうこのような新しいツールを使用することで保持と解放排他性と一意性のチェックなどの処理を省略できますまたこれらのツールを使ってバイナリパーサの速度と安全性を高めるための新しいオープンソースライブラリを紹介しますそれがSwift Binary Parsingライブラリですこのライブラリは速度を重視し数種類の安全性を管理するためのツールを備えていますまたSwiftには誰もが望むコード高速化のためのツールが用意されていますしかし高速化が容易でない場合もありますこのセッションではコード内で実行に時間がかかっている場所を特定していくつかの方法でパフォーマンス最適化を試みます適切なアルゴリズムの選択不要な割り当ての排除排他性チェックの排除ヒープからスタックへの割り当ての移行そして参照カウントの削減ですここからは私が作った簡単なアプリの内容を見ていきますこのアプリは QOIという形式の画像を表示するビューアですこの画像形式に対応する自作パーサが含まれています QOIはロスレス画像形式です仕様が1ページに収まるほどシンプルなので様々なアプローチを試してそのパフォーマンスを確認する場合に適しています QOI形式はバイナリ形式の標準イディオムを使用します固定サイズのヘッダに続くデータセクションには数が動的に変化する多様なサイズのエンコード済みピクセルが含まれますエンコード済みピクセルの形式としては RGB/RGBA値、前のピクセルとの差異、前に表示されたピクセルのキャッシュの参照、前のピクセルの繰り返し回数がありますでは私のQOIパーサアプリを使ってみましょう
このアイコンファイルを開きますわずか数キロバイトなのですぐに読み込まれます
この鳥の写真は少しサイズが大きいです読み込みに数秒かかる場合があります読み込まれましたなぜ時間がかかるのでしょうか実際のデータで顕著な速度低下が見られる場合アルゴリズムまたはデータ構造の使用方法が誤っている可能性が高いと言えます Instrumentsを使ってこの問題の原因を見つけて解決しましょう私の解析ライブラリ内に読み込みが遅かった鳥の画像を解析するテストを作成しました実行ボタンをクリックしてテストを実行すると
数秒後に問題なく終了しますこのテストを使った正確性のチェックに加えて Instrumentsでテストをプロファイリングしパフォーマンスを確認することもできます次に実行ボタンを副ボタンでクリックしますテストをプロファイリングするためのオプションがあります
とても便利な機能でテストをプロファイリングする際コード内の興味のある部分に焦点を当てることができますこのオプションをクリックして Instrumentsを起動します
Instrumentsのテンプレート選択ダイアログにコードのパフォーマンスを把握するために役立つさまざまなテンプレートが表示されます今回は2種類のinstrumentを使用するので空白のテンプレートで開始しましょう
instrument追加ボタンをクリックして instrumentを追加しますパーサによるメモリの割り当て状況を調べたいので Allocations instrumentを追加しますまた時間がかかっている場所を知りたいので Time Profiler instrumentを追加します
Time Profilerはパフォーマンスの問題を調べる際に最初に使用するべき機能ですサイドバーを非表示にして結果が大きく表示されるようにしましょう次に記録ボタンをクリックしてテストを開始します
結果ウインドウに様々なデータが表示されます
プロファイルに含まれるinstrumentはウインドウの上部に一覧表示されますまず「Time Profiler」を使用するのでこれを選択しておきます下部には選択中のツールの詳細ビューが表示されます左側にはキャプチャされたコールがリスト表示され右側には現在選択中のコールの高負荷のスタックトレースが表示されます
まず到達方法にかかわらず最も頻繁にキャプチャされたコールを確認しましょうボタンをクリックして
チェックボックスを選択しますグラフィカルビューに切り替えるには詳細ビューの上部のボタンをクリックしますビューが切り替わりプロファイルのフレームグラフが表示されます
フレームグラフの各バーはプロファイリング中に各コールがキャプチャされた回数の割合を示していますこれを見ると「platform_memmove」と表記されたバーがプロセスの大部分を占めています同じシンボルがスタックトレースにもあります memmoveはデータをコピーするシステムコールなのでこの巨大なバーはパーサがほとんどの時間をデータの読み取りよりもコピーに費やしていることを示していますこれは望ましくない動作ですコードのどの部分がこのコピー動作を引き起こしているか調べてみましょうスタックトレースにすべてのフレームを表示するためビューの上部にあるボタンをクリックします
トレースの一番上にシステムコールが表示され platform_memmoveも含まれていますまた Foundation Data型の特殊なバージョンのメソッドもいくつか表示されていますこの特殊なメソッドはスタックトレースまたはデバッグ中に目にすることもありますこの特殊なメソッドは Swiftコンパイラによって生成された型固有バージョンのジェネリックコードです
こちらが私が定義したメソッドである readByteです
コード内で問題に最も近い関数がこれですのでここから始めるのがよいでしょうこのメソッドにジャンプするため副ボタンでクリックしてを選択します
Xcodeのこの部分で readByteメソッドが宣言されていますこの行に自動的に移動しますここで最初のバイトをドロップしてデータイニシャライザを呼び出しています Instrumentsを使用することでライブラリの速度低下の原因の可能性があるすべてのmemmoveコールを特定し大量のコピー処理を発生させているコード行にジャンプすることができました
このヘルパメソッドは本当に重要です私の解析コードは readByteを何度も呼び出しながら Rawバイナリデータを消費しているからです
readByteメソッドを呼び出すたびに最初のバイトを返してデータの開始を前方に移動するためデータが縮小すると考えていましたしかし実際は 1バイト読み取るたびにデータのコンテンツ全体を新しい割り当て先にコピーします考えていたよりもはるかに重い処理でしたこの間違いを正しましょう Xcodeに戻って readByteメソッドを編集します
Data型は両端から縮小する仕様なので「popFirst()」というコレクションメソッドを利用できます popFirst()はデータの最初のバイトを返した後コレクションの冒頭部分を前方にスライドさせ 1バイトだけ縮小させます私が求めていた動作です
これを修正したらテストに戻りプロファイルを再度実行します
Instrumentsが自動的に開きます同じプロファイリング構成で既にテストが実行されています問題ありませんね platform_memmoveの巨大なバーがフレームグラフから消えました
ベンチマークを実行すると変更の結果として実行速度が大幅に改善されたのがわかります素晴らしい結果ですがこのようなアルゴリズム変更がもたらすのはこうした明白な変化だけではありません元のバージョンでは画像のサイズとその解析に要する時間の関係性は二次関数的なものでした解析する画像が大きいほど解析にかかる時間が大幅に長くなりましたコピーの問題を修正したことでこの関係が線形的になります画像のサイズとその解析時間の関係性はもっと直接的なものになりますここからさらに修正を加えてこの線形パフォーマンスを改善することでそれぞれの修正方法を直接比較できるようになります
この問題はいったん置いておいてパフォーマンス悪化の主要原因の2つ目過剰な割り当てに注目しましょう現在最も重いスタックトレースはどれでしょうかこれらのコールは Swift配列の割り当て／割り当て解除を行うメソッドへのトラフィックが多いことを示していますメモリの割り当て／割り当て解除は高コストなのでこの過剰な割り当ての原因を突き止めてそれを解消できればパーサを高速化できるでしょうパーサが実行している割り当てを確認するために先ほど追加した Allocations instrumentを使用しますいくつかの指標によりこのコードが不必要な割り当てを行っていることがわかります第1は数が多すぎることです 1つの画像の解析で 100万回近くの割り当てが行われていますもっと効率化できるはずです第2にこれらのほぼすべてが一時的な割り当てであることがわかります Allocations instrumentにより一時的なものとしてマークされています
問題の原因を見つけるために詳細パネルをコールツリービューに切り替えましょうポップアップボタンをクリックしてを選択します
一番上のスレッドを選択しスタックトレースでこの問題に最も近いコード内の領域を探しますこのスタックトレースは反転していないのでトレースの一覧の一番下を見る必要があります私のパーサの最初のシンボルはこのRGBAPixel.dataメソッドです
このメソッドをクリックするとコールツリーの詳細ウインドウに表示されますこのメソッドを副ボタンでクリックしを選択してソースに直接ジャンプします
このメソッドが過剰な割り当ての原因のようですこのメソッドは呼び出されるたびにピクセルのRGB値または RGBA値が含まれる配列を返しますつまり呼び出されるたびに配列を作成し 3つ以上の要素を格納できるスペースを割り当てます
どこで使用されているかを調べるにはこの関数名を副ボタンでクリックしてを選択します
呼び出し元はメインの解析関数にあるこのクロージャですこれはこの大きなflatMapと prefixチェーンの一部にすぎませんこのコードが膨大な数の個別割り当てを行う理由を理解するために割り当てがどのように重なっていくのか段階的に見ていきましょう
まずreadEncodedPixelsメソッドがバイナリデータをピクセルにエンコードします先ほど述べたようにこれは多様なピクセルタイプでありこれを格納できるスペースを割り当てる必要があります
次にエンコードされたピクセルごとに decodePixelsが呼び出され 1つ以上のRGBAピクセルを生成しますほとんどのエンコーディングでは 1ピクセルのみが出力されますが 1つのエンコーディングが前のピクセルを一定回数繰り返すよう指定していますこれをサポートするためにdecodePixelsは常に配列を返しますこの配列のそれぞれを割り当てる必要があります
flatMapの「フラット化」部分が先ほど作成された小さな配列をすべて受け取ってマージし 1つのはるかに大きな配列を作成しますこれは新しい割り当てです先ほど作成した小さな配列はすべて割り当て解除されます
このprefixメソッドによって生成できるピクセル数に上限が設定されています
2つ目のflatMapはまず Allocations instrumentを使用した時にフラグが付けられた RGBAPixel.dataメソッドを呼び出します先ほどこのメソッドが3要素または4要素を含む配列を返すことを確認しましたこれを見ると最終的な画像の 1ピクセルごとに3要素または4要素の配列が1つずつ生成されることがわかりますコンパイラによってこの過剰な割り当てを一部最適化できる可能性がありますがトレースで見たようにそれが常に行われるとは限りません
次に小さな配列群が1つの大きな新しい配列に再びフラット化されます最後にRGBピクセルまたは RGBAピクセルのデータの大きな配列が新しいDataインスタンスにコピーされ返すことが可能になります
このコードにはある種の洗練された美しさがあります短いメソッド呼び出しの連鎖に多くのパワーが詰め込まれていますしかし短いからといって速いわけではありませんこうした様々な手順を処理して最終的にDataインスタンスを返すのではなく最初にデータを割り当てた後でバイナリソースデータからデコードする際に各ピクセルを書き込めばまったく同じ処理を実行しながらもこうした中間的な割り当てが一切不要になります先ほどの解析関数に戻りましょうこのメソッドを修正して余分な割り当てをすべて排除します
まず「totalBytes」つまり結果データの最終的なサイズを計算します次に「pixelData」に適切なサイズのストレージを割り当てます「offset」変数は書き込まれたデータの量を追跡しますこの事前割り当てによりバイナリデータを扱う過程で追加の割り当てが不要になります
次に各データを解析してただちに処理します switchステートメントを使用して解析済みピクセルを処理できます
実行を指示するエンコード済みピクセルについては必要な回数だけループさせて毎回ピクセルデータを書き出します
他の種類のピクセルについてはデコードしてデータに直接書き込みますこれは完全な書き換えであり返す必要があるデータを除いて割り当てを行いませんテストを再度プロファイリングして問題が修正されたことを確認しましょう
割り当ての数が大幅に減ったことがすぐにわかりますコード内の実際の割り当て数を確認するためにフィルタを使用しますウインドウの下部にあるフィルタフィールドをクリックして「QOI.init」と入力します
これによりスタックトレースに QOI.initを含まないコールツリーが除外されます残った行を見るとパーサコードが少数の割り当てしか実行せず合計で2MBもないことがわかります Optionキーを押しながら三角印をクリックするとコールツリーが展開されます
展開されたツリーに必要な情報があります
割り当てが実行されるのは結果の画像が格納されるDataのみです
ベンチマークを見ると大きく改善されていることがわかります過剰な割り当てを排除することで実行時間が半分以下に短縮されました
ここまでパーサのアルゴリズムに2つの変更を加えることで大量の誤コピーを解消し割り当て処理の数を減らしました以降のいくつかの改善ではさらに高度な手法を使って実行時に行われる自動メモリ管理処理の多くを Swiftコンパイラによって解消します
まず配列やその他のコレクション型がどのように機能するかについて説明します SwiftのArray型は処理速度が速く安全で使いやすいため Swiftで最も人気のあるツールの1つです配列は必要に応じて拡大縮小できるため事前に作業対象のアイテム数を把握しておく必要がありません背後でSwiftが自動的にメモリを処理します配列も値型ですつまり配列のコピーに加えた変更は他のコピーに影響を与えません配列のコピーを作成する場合は配列を別の変数に割り当てるか関数に渡します Swiftでは要素が即座に複製されることはありませんその代わりにコピーオンライトと呼ばれる最適化手法が使用されますこれによりいずれかの配列を実際に変更するまで複製が遅延されます
このような機能を備えた配列は優れた汎用コレクションですがトレードオフもいくつかあります動的なサイズ変更と複数の参照をサポートするため配列のコンテンツは多くの場合ヒープ上の別の割り当てに格納されます Swiftランタイムは参照カウントを使用して各アレイのコピー数をトラッキングします変更が加えられると配列が一意性をチェックし要素をコピーする必要があるかどうか確認しますさらに Swiftはコードを安全に保つために排他性を適用しますつまり 2つの異なるものが同じデータを同時に変更できないようにしますこの規則は多くの場合コンパイル時に適用されますが実行時にのみ適用される場合もあります低レベルの概念について学習したところで次はプロファイリングでどのように表示されるかを見ていきますまず排他性のランタイムチェックについてですこれによってプログラムの変更が必要になり最適化が妨げられる可能性がありますこれから排他性チェックについて説明するわけですがここに良い例題がありますパフォーマンスを改善したことで Instrumentsがパーサプロセスを確認する十分な時間がなくなりました解析コードをループすることで確認する時間を少し増やすことができます 50回もあればよいでしょう
改善したプロファイルを見てみましょう
排他性テストはトレース内で「swift_beginAccess」シンボルと「swiftendAccess」シンボルで表されますもう一度ウインドウの下部にあるフィルタボックスをクリックしてシンボル名を入力します
フレームグラフの上部に swift_beginAccessが数回現れておりそのすぐ下にこのチェックを必要とするシンボルがありますこのシンボルは直前のピクセルとピクセルキャッシュのアクセサであり私のパーサの Stateクラスに格納されています Xcodeに戻ってその宣言を探してみましょうここですね Stateはフレームグラフに表示されていた 2つのプロパティを持つクラスです Classインスタンスの変更は Swiftが実行時に排他性をチェックする必要がある状況の1つなのでこのような結果になった原因はこの宣言にありますこのチェックを排除するにはこれらのプロパティをクラスの外に移動しそれを直接パーサ型に入れます
次に検索置換を実行して previousPixelとpixelCacheへの「state.」アクセスを削除します
ビルドするともう少し修正が必要なことをコンパイラが知らせてくれます
stateプロパティがクラス内でネストされなくなるためイミュータブルのメソッドではこれを変更できません
この修正を適用してメソッドをミュータブルにします
修正はもう1か所あります
これで完了です変更が終わりましたのでテストに戻りましょう
プロファイルを再記録して変更の結果を確認します
再びswift_beginAccessにフィルタをかけます
何も表示されませんこれで実行時の排他性チェックが完全に削除されました状態変数をもう一度見てみましょうここで Swiftの新機能を使用してヒープメモリからスタックメモリにデータを移動し排他性チェックが入る余地をなくしましょうこのパーサのピクセルキャッシュは RGBAPixelの配列です 64個の要素を持つよう初期化されサイズは変更されませんこのキャッシュは新しいInlineArray型を使用するのに最適です InlineArrayはSwift 6.2の新しい標準ライブラリ型です通常の配列と同様連続するメモリ内に同じ種類の要素を格納しますしかし大きな違いがいくつかありますまず InlineArrayはコンパイル時に固定サイズが設定されます通常の配列では追加や削除が可能ですが InlineArrayは新しい値ジェネリクス機能を使用してそのサイズを型の一部にしますつまり InlineArrayの要素に変更を加えることはできますがサイズが異なる配列へのInlineArrayの追加、削除、割り当てはできません
次にその名前が示すように InlineArrayを使用すると要素が常にインラインで格納され個別に割り当てられません InlineArrayはコピー間でストレージを共有せずコピーオンライトを使用しません代わりにコピーを作成するたびにコピーされますそのため通常の配列で必要となる参照カウント、一意性チェック、排他性チェックが不要です InlineArrayのコピー動作が異なることはある意味で諸刃の剣となります配列を使用するために異なる変数間またはクラス間でコピーの作成または参照の共有が必要な場合 InlineArrayは適切でない可能性がありますただしこの場合ピクセルキャッシュは固定サイズの配列であり変更が適用されますが決してコピーされません「InlineArray」が適している場所ですね
最後の最適化では標準ライブラリの新しいSpan型を使用して解析中に発生する参照カウントの大部分を排除します Time Profilerのフレームグラフに戻ってもう一度フィルタを適用し QOIパーサのみを見てみましょうフィルタボックスに「QOI.init」と入力します
解析イニシャライザを含むスタックトレースのみがビューに表示されます retainシンボルとreleaseシンボルに注目しましょうこのピンク色のバーがswift_retainで 7%のサンプルに出現していますこれがswift_releaseでこれも7%に出現します先ほどお話しした一意性チェックはここにあります 3%のサンプルに出現しています
これがどこから来ているのか調べるために swift_releaseに戻りますこれまでと同様最も負荷の高いスタックトレースをスキャンして最初のユーザ定義メソッドを見つけます最初に使用したものと同じ readByteメソッドのようです
今回扱うのはアルゴリズムの問題ではなく「Data」自体の使用方法です「Array」と同様に「Data」も通常はメモリをヒープに格納し参照カウントの必要がありますこのような参照カウント処理つまり保持と解放は非常に効率的ですがそれが短いループで発生すると膨大な時間が消費される場合がありますそれがこのメソッドの問題ですこれに対処するには Dataや Arrayなどの高レベルのコレクション型から参照カウントの爆発的増加を起こさない型に処理を移行する必要があります Swift 6.2までは withUnsafeBufferPointerなどのメソッドを使用してコレクションの基盤ストレージにアクセスしていましたこれらのメソッドを使用するとメモリを手動で管理でき参照カウントが発生しませんただしコードの安全性は損なわれます
ポインタが安全でない理由を考えてみましょうポインタはSwiftの安全性保証の多くを回避するため安全でない状態で呼び出されますポインタは初期化メモリと未初期化メモリをどちらもポイントできいくつかの型の保証を適用せずコンテキストからエスケープできるため割り当てられていないメモリにアクセスするリスクが生じます安全でないポインタを使用する場合コードの安全性を確保する責任はデベロッパ自身が負うことになりますコンパイラは助けてくれませんこのprocessUsingBuffer関数は安全でないポインタを適切に扱っています使用範囲全体が安全でないバッファポインタクロージャ内に収まり計算の結果のみが最後に返されますこれに対してこの「getPointerToBytes()」関数は危険ですこれには重大なエラーが2つ含まれていますこの関数はバイトの配列を作成し UnsafeBufferPointerメソッドを使って呼び出しを行いますしかしクロージャへのポインタの使用を制限せずに外側スコープへのポインタを返しますエラーその1 さらに悪いことに次にこのコードはこの関数から有効でなくなったポインタを返しますエラーその2 2つのエラーによってポインタの有効時間がポイント先の有効時間を超えて延長されるため移動または割り当て解除されたメモリへの危険な参照が残されることになりますこれに対処するため Swift 6.2にはSpanと呼ばれる新しい型のグループが導入されました Spanはコレクションに属する連続メモリを扱うための新しい手段となります Spanの新しい「エスケープ不可」言語機能によりコンパイラは連続メモリの有効時間を提供元のコレクションに関連付けることができます Spanがアクセスを提供するメモリはそのSpanの間だけ存続することが保証されるため参照が残存する可能性がなくなりますすべてのSpan型はエスケープ不可として宣言されるためコンパイラではエスケープを実行できず取得元のコンテキストの外部に Spanを返すこともできませんこの「processUsingSpan」メソッドのようにポインタよりもシンプルで安全なコードをSpanによって作成できます Spanに配列の要素を含めるには spanプロパティを使用しますクロージャを使わずに危険なポインタと同じくらい効率的に配列のストレージにアクセスでき危険性を排除できます以前の危険な機能を修正しようとすると「エスケープ不可」言語機能が動作しているのがわかります最初にわかるのはこの「Span」を含む同じ関数シグネチャを作成することもできないことです Spanの有効期間は提供元のコレクションに関連付けられるためコレクションまたはSpanが渡されなければ渡されるSpanの有効期間を取得することができません
SpanをクロージャでキャプチャしてコンパイラからSpanを隠してみましょうこの関数では配列を作成してSpanにアクセスしそのSpanをキャプチャするクロージャを返そうとしていますしかしそれもうまくいきません Spanをキャプチャするとエスケープが可能になるためコンパイラはその有効時間がローカル配列に依存することを指摘します Spanがスコープをエスケープしないこのコンパイラチェック済み要件は保持と解放が必須ではないことを意味します安全でないバッファを一切の危険なく活用できるようになります Spanファミリには読み取り専用かつミュータブルなSpanの型付きバージョンと Rawバージョンが含まれ既存のコレクションを扱うことができます新しいコレクションの初期化に使用できる出力Spanもありますこのファミリには安全で効率的な Unicode処理のための新しい型である UTF8Spanも含まれています
コードに戻って RawSpanにこのreadByteメソッドを実装しましょう
まずRawSpanのextensionを追加し
readByteメソッドを定義します
このRawSpanのAPIはDataとは少し異なりますが先ほど実装したものと同じ処理を行います最初のバイトをロードして RawSpanを縮小した後ロードされた値を返しますこのunsafeLoadメソッドは特定の種類の型をロードすると危険である可能性があるためこの方法でのみ命名してください組み込み整数型はこのようにしてロードすると常に安全です
次に解析メソッドを更新しましょう
この2つの解析メソッドではパラメータとしてDataではなく RawSpanを使用する必要があります
また呼び出し側にも変更を加える必要があります
データそのものを渡すのではなくデータのRawSpanを取得してそれを解析メソッドに渡します DataのRawSpanには bytesプロパティを使ってアクセスしますこのrawBytes値はエスケープ不可ですこの関数からこれを返すことはできませんが問題なくこれを解析メソッドに渡すことができます
この変更でRawSpanを使用するための更新が完了しました細かな作業をもっと省くために解析メソッドに新しいOutputSpanを導入することもできます
0に初期化されたデータを作成するのではなく新しいrawCapacity イニシャライザに含まれる OutputSpanを使用して未初期化データに段階的に入力します
OutputSpanは書き込まれたデータの量を追跡するためそのcountプロパティを独立した offset変数の代わりに使用できます
さらにwrite(to:)メソッドの別のバリエーションを使用し Dataインスタンスではなく outputSpanに書き込みます
ではこのメソッドの実装を確認しましょう
write(to:)メソッドはピクセルの各チャネルごとにOutputSpanのappendメソッドを呼び出すことができます OutputSpanはこのような用途を想定したエスケープ不可の型であるため「Data」インスタンスに書き込むよりもシンプルかつ効率的で安全でないバッファポインタにドロップダウンするよりも安全です以上の変更が完了したらテストに戻って新しいプロファイルを記録しましょう
QOI.initでフィルタリングします
フレームグラフを見ると swift_retainと swift_releaseのブロックがなくなりました良い結果が得られましたここで InlineArrayとRawSpanを導入した結果を見てみましょう
今回加えた変更によって安全でないコードに頼ることなくメモリ管理の修正によって解析時間を6分の1に短縮できましたこれは二次関数的アルゴリズムの除去後と比較して16倍高速であり当初の状態と比較すると 700倍以上高速化されています今回は様々な話題を取り上げましたこの画像解析ライブラリを修正するためにアルゴリズムに2つの変更を加え動作の効率性を高め割り当て数を減らしました実行時のメモリ管理を解消するために新しい標準ライブラリ型である InlineArrayとRawSpanを使用しましたそして新しいエスケープ不可言語機能について学びました新しいSwiftバイナリ解析ライブラリはこの同じ機能の上に構築されていますデベロッパはこのライブラリを使ってバイナリ形式の安全で効率的なパーサを開発し様々な種類の安全性を扱うことができますこのライブラリは解析イニシャライザを含む包括的なツールセットであり Rawバイナリデータの値を安全に利用するために役立ちます
こちらは新しいライブラリを使用して作成された QOIヘッダ用のパーサの例ですこれはその機能の一部を示しています ParserSpanはバイナリデータを解析するためにカスタマイズされたRawスパン型ですまた解析イニシャライザによって整数オーバーフローを防ぎ符号属性、ビット幅、バイト順を指定できますこのライブラリにはカスタムRaw表現可能型のための検証用パーサと信頼できない新たな解析値を使って安全に計算を行うためのオプション生成オペレータも含まれます
Apple社内では既にバイナリ解析ライブラリが使用されており今日から一般公開されますぜひ一度ご覧になりお試しください Swiftフォーラムに投稿するか GitHubの open issueまたはpull requestからコミュニティにご参加ください Swiftコードの最適化についてご視聴いただきありがとうございました XcodeとInstrumentsを使ってアプリで高性能が求められる部分のテストをプロファイリングしましょう新しいInlineArray型とSpan型についてはドキュメントをご覧になるか新バージョンの Xcodeをダウンロードしてください WWDCをお楽しみください

import Foundation

extension Data {
  /// Consume a single byte from the start of this data.
  mutating func readByte() -> UInt8? {
    guard !isEmpty else { return nil }
    return self.popFirst()
  }
}

9:56 - RGBAPixel.data(channels:) method

extension RGBAPixel {
  /// Returns the RGB or RGBA values for this pixel, as specified
  /// by the given channels information.
  func data(channels: QOI.Channels) -> some Collection<UInt8> {
    switch channels {
    case .rgb:
      [r, g, b]
    case .rgba:
      [r, g, b, a]
    }
  }
}

10:21 - Original QOIParser.parseQOI(from:) method

extension QOIParser {
  /// Parses an image from the given QOI data.
  func parseQOI(from input: inout Data) -> QOI? {
    guard let header = QOI.Header(parsing: &input) else { return nil }
    
    let pixels = readEncodedPixels(from: &input)
      .flatMap { decodePixels(from: $0) }
      .prefix(header.pixelCount)
      .flatMap { $0.data(channels: header.channels) }

    return QOI(header: header, data: Data(pixels))
  }
}

12:53 - Revised QOIParser.parseQOI(from:) method

extension QOIParser {
  /// Parses an image from the given QOI data.
  func parseQOI(from input: inout Data) -> QOI? {
    guard let header = QOI.Header(parsing: &input) else { return nil }
    
    let totalBytes = header.pixelCount * Int(header.channels.rawValue)
    var pixelData = Data(repeating: 0, count: totalBytes)
    var offset = 0
    
    while offset < totalBytes {
      guard let nextPixel = parsePixel(from: &input) else { break }
      
      switch nextPixel {
      case .run(let count):
        for _ in 0..<count {
          state.previousPixel
            .write(to: &pixelData, at: &offset, channels: header.channels)
        }
      default:
        decodeSinglePixel(from: nextPixel)
          .write(to: &pixelData, at: &offset, channels: header.channels)
      }
    }
    
    return QOI(header: header, data: pixelData)
  }
}

15:07 - Array behavior

var array = [1, 2, 3]
array.append(4)
array.removeFirst()
// array == [2, 3, 4]

var copy = array
copy[0] = 10      // copy happens on mutation
// array == [2, 3, 4]
// copy == [10, 3, 4]

19:47 - InlineArray behavior (part 1)

var array: InlineArray<3, Int> = [1, 2, 3]
array[0] = 4
// array == [4, 2, 3]

// Can't append or remove elements
array.append(4)
// error: Value of type 'InlineArray<3, Int>' has no member 'append'

// Can only assign to a same-sized inline array
let bigger: InlineArray<6, Int> = array
// error: Cannot assign value of type 'InlineArray<3, Int>' to type 'InlineArray<6, Int>'

20:23 - InlineArray behavior (part 2)

var array: InlineArray<3, Int> = [1, 2, 3]
array[0] = 4
// array == [4, 2, 3]

var copy = array    // copy happens on assignment
for i in copy.indices {
    copy[i] += 10
}
// array == [4, 2, 3]
// copy == [14, 12, 13]

23:13 - processUsingBuffer() function

// Safe usage of a buffer pointer
func processUsingBuffer(_ array: [Int]) -> Int {
    array.withUnsafeBufferPointer { buffer in
        var result = 0
        for i in 0..<buffer.count {
            result += calculate(using: buffer, at: i)
        }
        return result
    }
}

23:34 - Dangerous getPointerToBytes() function

// Dangerous - DO NOT USE!
func getPointerToBytes() -> UnsafePointer<UInt8> {
    let array: [UInt8] = Array(repeating: 0, count: 128)
    // DANGER: The next line escapes a pointer
    let pointer = array.withUnsafeBufferPointer { $0.baseAddress! }
    // DANGER: The next line returns the escaped pointer
    return pointer
}

24:46 - processUsingSpan() function

// Safe usage of a span
@available(macOS 16.0, *)
func processUsingSpan(_ array: [Int]) -> Int {
    let intSpan = array.span
    var result = 0
    for i in 0..<intSpan.count {
        result += calculate(using: intSpan, at: i)
    }
    return result
}

25:07 - getHiddenSpanOfBytes() function (attempt 1)

@available(macOS 16.0, *)
func getHiddenSpanOfBytes() -> Span<UInt8> { }
// error: Cannot infer lifetime dependence...

25:28 - getHiddenSpanOfBytes() function (attempt 2)

@available(macOS 16.0, *)
func getHiddenSpanOfBytes() -> () -> Int {
    let array: [UInt8] = Array(repeating: 0, count: 128)
    let span = array.span
    return { span.count }
}

26:27 - RawSpan.readByte() method

@available(macOS 16.0, *)
extension RawSpan {
  mutating func readByte() -> UInt8? {
    guard !isEmpty else { return nil }
    
    let value = unsafeLoadUnaligned(as: UInt8.self)
    self = self._extracting(droppingFirst: 1)
    return value
  }
}

28:02 - Final QOIParser.parseQOI(from:) method

/// Parses an image from the given QOI data.
mutating func parseQOI(from input: inout RawSpan) -> QOI? {
  guard let header = QOI.Header(parsing: &input) else { return nil }
  
  let totalBytes = header.pixelCount * Int(header.channels.rawValue)
  
  let pixelData = Data(rawCapacity: totalBytes) { outputSpan in
    while outputSpan.count < totalBytes {
      guard let nextPixel = parsePixel(from: &input) else { break }
      
      switch nextPixel {
      case .run(let count):
        for _ in 0..<count {
          previousPixel
            .write(to: &outputSpan, channels: header.channels)
        }
        
      default:
        decodeSinglePixel(from: nextPixel)
          .write(to: &outputSpan, channels: header.channels)
        
      }
    }
  }
  
  return QOI(header: header, data: pixelData)
}

28:31 - RGBAPixel.write(to:channels:) method

@available(macOS 16.0, *)
extension RGBAPixel {
  /// Writes this pixel's RGB or RGBA data into the given output span.
  @lifetime(&output)
  func write(to output: inout OutputRawSpan, channels: QOI.Channels) {
    output.append(r)
    output.append(g)
    output.append(b)
    
    if channels == .rgba {
      output.append(a)
    }
  }
}

関連する章

リソース

関連ビデオ

WWDC25

WWDC24