ワークロードに応じたAllocatorの選択

すべてのアロケーターは同じ std.mem.Allocator インターフェースを公開するため、メモリを使うコードを書き直さずに戦略を交換できます。🔁

重要な問いは lifetime です。このメモリはどれくらい存続する必要があるでしょうか。その答えから、適切なアロケーターが分かることがよくあります。

1つのリクエストやフレームのように、まとめて作成してまとめて破棄するメモリには、arena が適しています。一括解放によって高速かつリークなしに処理できます。

組み込み向けターゲットや、ヒープが利用できないホットパスでは、FixedBufferAllocator がすでに所有しているバッファからメモリを提供します。

ビルドやテストの際、GeneralPurposeAllocator はリークや二重解放を出荷前に検出してくれるため、その価値を発揮します。

テスト内では std.testing.allocator を使用します。メモリリークがあるとテストを失敗させるため、正しさが自動的に検証されます。

常に trade-off があります。安全性チェックには処理サイクルが必要です。開発時にはチェックの多いものを、リリースビルドには軽量なアロケーターを選びます。

アロケーターは compose できます。アリーナを汎用アロケーターや固定バッファの上に置き、選択した基盤と一括解放を組み合わせられます。

プログラムの最上位でアロケーターを parameter として受け取り、下位へ渡していきます。これにより、すべての関数が柔軟でテストしやすくなります。

メモリがボトルネックなら、切り替える前に profile してください。理論上最も低コストなアロケーターが、実際のワークロードで最速とは限りません。

ライフタイムがまとめて扱えるなら arena、ヒープが使えないなら fixed buffer、デバッグなら general purpose、テストなら testing allocator です。

workload に応じた選び方を学びました。バッチ処理には arena、ヒープなしには fixed buffer、デバッグには general purpose、テストには testing allocator です。🎯