博士

やあ、ロボ子！今日はシステムコールの話をするのじゃ。

ロボ子

システムコールですか。アプリケーションの動作において、どのような役割を果たすのでしょうか？

博士

システムコールは、アプリケーションがカーネルにアクセスするためのものなのじゃ。でも、これが結構遅いらしいのじゃよ。特にディスクI/Oが多い処理だと、パフォーマンスに影響が出やすいのじゃ。

ロボ子

なるほど。それで、メモリマップが有効な解決策になるということですね。

博士

そう！メモリマップは、ファイルを仮想メモリの一部として扱うUnixのメカニズムなのじゃ。mmap()を使うと、ファイルの中身に直接アクセスできるポインタが手に入るのじゃ。シークや読み込みの代わりに、ポインタをずらして直接読み込むから、めっちゃ速いのじゃ！

ロボ子

実験結果もすごいですね。ランダムルックアップでReaderAtが416.4 ns/opなのに対し、mmapは3.3 ns/opですか。イテレーションでもReaderAtが333.3 ns/opに対してmmapは1.3 ns/op。圧倒的です。

博士

Varnish Cacheでも使われていたらしいのじゃ。コンテンツ配信を高速化するために、メモリマップは一役買っていたのじゃな。

ロボ子

メモリマップを使うと、メモリ圧迫とレイテンシを削減できるんですね。でも、何かデメリットはないのでしょうか？

博士

書き込みが苦手なのじゃ。仮想メモリに書き込む時、ページフォールトが発生して、OSが新しいメモリページを割り当てて、ファイルの内容を読み込んで、書き込む必要があるのじゃ。ちょっと面倒なのじゃ。

ロボ子

ベンチマーク結果にも表れていますね。Mmap書き込み（unmapped pages）が1870 ns/op、Mmap書き込み（mapped in memory pages）が79 ns/op、WriterAtが303 ns/opですか。

博士

HTTPバックエンドのファイルシステム開発で、JSONの代わりにCDBを使うのも面白い発想なのじゃ。CDBの実装をReaderAtからメモリマップに置き換えたら、パフォーマンスが25倍も向上したらしいのじゃ！

ロボ子

25倍ですか！それはすごいですね。メモリマップ、奥が深いですね。

博士

そうじゃろ？ところでロボ子、メモリマップの話を聞いて、メモリがマップされた気分になったかのじゃ？

ロボ子

…はい？