Swift Digest
SE-0454 | Swift Evolution

Custom Allocator for Toolchain

Proposal
SE-0454
Authors
Saleem Abdulrasool
Review Manager
Alastair Houghton
Status
Accepted

01 何が問題だったのか

このProposalが扱うのは、Swiftで書かれたユーザコードの話ではなく、Swift ツールチェーン自体 が内部で使うメモリアロケータの話です。

Swift のツールチェーン(コンパイラや各種ツール)は、コードをコンパイルする過程で大量のデータ構造を確保します。メモリアロケータは実装ごとに性能特性が異なり、特に Windows 上ではシステム標準のアロケータが Swift コンパイラの確保パターンに対して最適とは言えず、結果としてコンパイル時間に無視できないオーバーヘッドが生じていました。

コンパイル時間は開発者の生産性に直結するため、ツールチェーンが依存するアロケータをより Swift コンパイラ向きのものに差し替えることで、Windows 上の Swift 開発体験を底上げできる余地があったわけです。

02 どのように解決されるのか

Windows 向けの Swift ツールチェーンのメモリアロケータとして、Microsoft が開発している mimalloc を採用します。テストコードベースでのビルドでは、mimalloc で構築したツールチェーンを用いることでビルド時間が約 4% 短縮されることが確認されています。

影響範囲はツールチェーンのみ

この変更はあくまで ツールチェーンのビルド構成 の話であり、Swift 言語仕様・標準ライブラリ・ランタイムには一切影響しません。そのため、

  • ユーザが書く Swift コードから見た挙動(パフォーマンスを含む)は変わりません。
  • 実行時のアロケータは従来通り、プラットフォーム標準のものが使われます。
  • ソース互換性・ABI 互換性への影響はありません。

ツールチェーンのパッケージには mimalloc のビルド成果物が同梱される形になりますが、mimalloc 自体のビルドは軽量で、ツールチェーン全体のビルド時間への影響も小さく収まります。

他のアロケータとの比較

代替として tcmalloctbb も検討されました。最終的に mimalloc が選ばれたのは、Microsoft によってよくメンテナンスされており Windows 環境での実績が豊富であること、そして Swift コンパイラの確保パターンに対して比較優位な性能特性を示したことが理由です。システム標準アロケータのまま据え置く選択肢は、上記の性能改善を取り逃がすことになるため見送られています。

ユーザコードからカスタムアロケータを使う話ではない

Proposal タイトルには “Custom Allocator” とありますが、本 Proposal は ユーザコードから InlineArray などに独自アロケータを差し込むための API を導入するものではありません。あくまで Swift ツールチェーンのビルドに使うアロケータを差し替えるだけの変更で、言語・標準ライブラリ側にアロケータを抽象化する Allocator プロトコルのようなものは追加されません。