Custom Allocator for Toolchain
01 何が問題だったのか
このProposalが扱うのは、Swiftで書かれたユーザコードの話ではなく、Swift ツールチェーン自体 が内部で使うメモリアロケータの話です。
Swift のツールチェーン(コンパイラや各種ツール)は、コードをコンパイルする過程で大量のデータ構造を確保します。メモリアロケータは実装ごとに性能特性が異なり、特に Windows 上ではシステム標準のアロケータが Swift コンパイラの確保パターンに対して最適とは言えず、結果としてコンパイル時間に無視できないオーバーヘッドが生じていました。
コンパイル時間は開発者の生産性に直結するため、ツールチェーンが依存するアロケータをより Swift コンパイラ向きのものに差し替えることで、Windows 上の Swift 開発体験を底上げできる余地があったわけです。
02 どのように解決されるのか
Windows 向けの Swift ツールチェーンのメモリアロケータとして、Microsoft が開発している mimalloc を採用します。テストコードベースでのビルドでは、mimalloc で構築したツールチェーンを用いることでビルド時間が約 4% 短縮されることが確認されています。
影響範囲はツールチェーンのみ
この変更はあくまで ツールチェーンのビルド構成 の話であり、Swift 言語仕様・標準ライブラリ・ランタイムには一切影響しません。そのため、
- ユーザが書く Swift コードから見た挙動(パフォーマンスを含む)は変わりません。
- 実行時のアロケータは従来通り、プラットフォーム標準のものが使われます。
- ソース互換性・ABI 互換性への影響はありません。
ツールチェーンのパッケージには mimalloc のビルド成果物が同梱される形になりますが、mimalloc 自体のビルドは軽量で、ツールチェーン全体のビルド時間への影響も小さく収まります。
他のアロケータとの比較
代替として tcmalloc や tbb も検討されました。最終的に mimalloc が選ばれたのは、Microsoft によってよくメンテナンスされており Windows 環境での実績が豊富であること、そして Swift コンパイラの確保パターンに対して比較優位な性能特性を示したことが理由です。システム標準アロケータのまま据え置く選択肢は、上記の性能改善を取り逃がすことになるため見送られています。
ユーザコードからカスタムアロケータを使う話ではない
Proposal タイトルには “Custom Allocator” とありますが、本 Proposal は ユーザコードから InlineArray などに独自アロケータを差し込むための API を導入するものではありません。あくまで Swift ツールチェーンのビルドに使うアロケータを差し替えるだけの変更で、言語・標準ライブラリ側にアロケータを抽象化する Allocator プロトコルのようなものは追加されません。