Swiftは当初、プロトコルの抽象化のために存在型コンテナ（現在はanyと呼ばれる）に完全に依存しており、これには値型をヒープにボックス化し、動的ディスパッチのためにウィットネステーブルを利用する必要がありました。Swift 5.1では、言語は不透明な結果型をsomeキーワードを通じて導入し、関数が実装の詳細を隠しつつ、コンパイラのための具象型情報を保持できるようにする逆ジェネリクスを実装しました。この進化は、型消去に伴う性能ペナルティ、特にヒープ割り当てや最適化機会の喪失に対処し、抽象化を犠牲にすることなく、Swift 5.6が存在型と不透明型を明示的に区別するための土台を築きました。
存在型コンテナ（any）は、値を3つの単語の表現を使用して格納します：インライン値バッファ（または大きな型の場合のヒープ割り当てへのポインタ）、値ウィットネステーブルへのポインタ、およびプロトコルウィットネステーブルへのポインタ。このボックス化メカニズムは、値型のためにヒープ割り当てを強制し、メソッド呼び出しのための動的ディスパッチを義務付けるため、コンパイラが特殊化やインライン化を実行することを妨げます。その結果、anyを使用するコードは、メモリ圧力の増加、ARCオーバーヘッド、キャッシュミスを伴い、特に決定論的なパフォーマンスが重要な高スループットまたはリアルタイムシステムにおいては有害です。
不透明型（some）は、具体的な型がコンパイラに知られているが呼び出し元からは隠される逆ジェネリックアプローチを利用し、ボックス化の必要を排除し、スタック割り当てを可能にします。コンパイラは、someの戻り型をジェネリック型パラメータと同様に扱い、型メタデータを不可視のパラメータとして渡し、間接参照なしで具体的な値の自然なメモリレイアウトを利用します。これにより、静的ディスパッチ、関数の特殊化、積極的なインライン最適化が可能になり、ABIの安定性を維持しながら、具体的な型が変更されても公共インタフェースのメモリレイアウトが変わらないようになります。
私たちは、高頻度のマーケットデータプロセッサを開発しており、MarketDataEventプロトコルの実装が取引所によって異なっていました（NYSEEvent、NASDAQEvent）。このシステムは、1秒間に何百万ものイベントをサブ10マイクロ秒のレイテンシで解析する必要がありました。
問題の説明: 初期アーキテクチャはfunc parse() -> any MarketDataEventを使用しており、各解析されたイベントが存在型ボックス化のためにヒープに割り当てを行いました。市場の変動時には、毎秒50,000回以上の割り当てが発生し、ARCの保持/解放サイクルとCPUキャッシュのスラッシングを引き起こし、レイテンシが25マイクロ秒に急上昇し、サービスレベル契約に違反しました。
解決策1: any MarketDataEventを引き続き使用する。利点: 単一の関数からの異種戻り型と簡単な異種コレクションを許可。 欠点: すべての値型イベントに対するヒープ割り当てが強制され、すべてのメソッド呼び出しに対する動的ディスパッチオーバーヘッド、そして最適化（インライン化）を妨げることになります。
解決策2: some MarketDataEvent（不透明型）を採用する。 利点: イベントをスタックに直接格納することでヒープ割り当てが排除され、静的ディスパッチと完全なコンパイラ特殊化が可能になり、レイテンシが65％減少しました。 欠点: 関数内のすべてのコードパスが同じ具象型を返す必要があり、条件解析ロジックのアーキテクチャ的なリファクタリングを別の関数や型特有のパーサに強制しました。
解決策3: ジェネリック関数シグネチャ<T: MarketDataEvent> func parse() -> Tを使用する。 利点: モノモーフィゼーションによる最大の最適化潜在能力。 欠点: 型推論を通して呼び出し元に具体的な型を公開し、コンパイラが各呼び出しサイトの専門的なコピーを生成し、実装の詳細のカプセル化を破ったためにバイナリサイズが大きくなりました。
選ばれた解決策: 私たちは解決策2を実装し、パーサを関連型制約を持つプロトコルにリファクタリングし、主要なホットパスのために不透明な結果型を使用しました。稀な異種コレクションの要件に対しては、軽量の列挙ラッパーを導入しました。 理由: スタック割り当ておよびデバーチャリゼーションによるパフォーマンスの向上が、均一な戻り型のアーキテクチャ制約を上回り、リファクタリングは条件ロジックをパーサから削除することによって関心の分離を実際に改善しました。
結果: レイテンシは3.5マイクロ秒に低下し、ヒープ割り当て率は99.7％減少し、CPUキャッシュヒット率は40％改善され、システムはハードウェアのアップグレードなしに4倍の市場データ量を処理できるようになり、安定したメモリ使用を維持しました。
1. なぜ不透明な結果型は、レジリエント構造体の保存プロパティとして使用できないのか、またこの制限はABI安定性要件とどのように相互作用しますか？ 不透明型は、固定のメモリレイアウト、サイズ、アライメントを計算するために宣言サイトで具体的な基礎型をコンパイラが知る必要があります。レジリエントライブラリは、バージョン間でABIの安定性を維持する必要があり、公共の構造体内の保存プロパティは、クライアントに可視な固定のオフセットとサイズを必要とします。some型は公共インタフェースから具体的な型を隠しますが、コンパイル時にバインドされるため、基礎実装を変更すると構造体のバイナリレイアウトが変更され、既存のコンパイルされたクライアントが壊れます。存在型（any）は、具体的な型の変更からABIを絶縁する一貫した三単語の間接参照レイヤーを使用することで、保存プロパティの唯一の実行可能なオプションとなります。
2. コンパイラは、不透明型のメソッドディスパッチを同じモジュール内とモジュール境界を越えてどのように異なって扱い、そしていつウィットネステーブルのディスパッチにフォールバックしますか？ 同じモジュール内では、コンパイラは通常、不透明な戻り型の関数を呼び出しサイトで専門化し、具体的な実装をインライン化し、仮想ディスパッチを完全に排除します。しかし、ライブラリアルバージョンが有効な場合にモジュール境界を越えると具体的な型が隠される可能性があり、コンパイラはジェネリクスと同様にウィットネステーブルディスパッチを使用することを余儀なくされます。存在型は常に存在型コンテナに格納されたウィットネステーブルを使用するのに対し、不透明型は型メタデータを隠されたジェネリックパラメータとして渡し、ランタイムがメタデータを通じて正しいウィットネステーブルを特定できます。フォールバックとしてのウィットネステーブルディスパッチは、コンパイラが不透明な境界のために専門化できない場合に特に発生しますが、その場合でも、ディスパッチは存在型コンテナの二重間接参照を回避し、より良いパフォーマンス特性を維持します。
3. as? またはMirror反映を使用して不透明型と存在型をキャストする際の特定のランタイムメタデータの違いは何ですか、そしてなぜ不透明型が存在型で成功するキャストに失敗することがあるのですか？
存在型コンテナ（any）は、その3単語構造内におけるプロトコルウィットネステーブルおよび型メタデータを保持し、準拠の即時のランタイム識別を可能にし、存在型またはその基礎具体型にキャストすることをサポートします。不透明型（some）は具体的な型の完全なメタデータを保持しますが、抽象化境界の背後に隠されているため、as?を介して異なるプロトコルにキャストするには、コンパイラが具体的な型のメタデータを通じて準拠ウィットネスを見つけるためのランタイムルックアップを発生させる必要があります。不透明型は、具体的な型が明示的に準拠していないプロトコルへのキャストに失敗することがありますが、それはランタイムが具体的なメタデータに対して検証するためです。対照的に、存在型は主なプロトコル準拠をキャッシュしており、特定のキャストを速くする一方で、具体的な型の全機能を隠すことがあります。