メモリマップファイルを使用する場合
ネットワークを介してデータのチャンクを受信し、それらをディスクに書き込むアプリケーションがあります。すべてのチャンクを受信すると、それらを実際に表す単一のファイルにデコード/再結合できます。
メモリマップドファイルを使用することが有用かどうか疑問に思います-最初に単一のチャンクをディスクに書き込むため、次にすべてがデコードされる単一のファイルのために。
私自身の考えでは、これは2番目のケースにのみ役立つ可能性があると考えています。
編集：これはC＃アプリであり、x64バージョンのみを計画しています。 （したがって、「最大の連続した空き領域」問題が発生しても問題になりません）
メモリマップファイルは、かなり大きなファイルの比較的小さな部分（ビュー）に繰り返しアクセスする必要があるシナリオに役立ちます。
このシナリオでは、オペレーティングシステムは、マップされたファイルの最近使用した部分のみをページインおよびページアウトすることにより、アプリケーションの全体的なメモリ使用量とページング動作を最適化するのに役立ちます。
さらに、メモリマップファイルは、コピーオンライトなどの興味深い機能を公開したり、共有メモリの基盤として機能したりできます。
シナリオでは、メモリマッピングされたファイルは、チャンクが順不同で到着した場合にファイルを組み立てるのに役立ちます。ただし、最終的なファイルサイズを事前に知る必要があります。
また、チャンクを書き込むために、一度だけファイルにアクセスする必要があります。したがって、明示的に実装された非同期I/Oを超えるパフォーマンス上の利点はありませんが、ファイルライターを正しく実装する方が簡単かつ迅速です。
.NET 4では、Microsoftはメモリマップファイルのサポートを追加しました。サンプルコードを含む包括的な記事がいくつかあります。 http://blogs.msdn.com/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx 。
メモリマップトファイルは、主にプロセス間通信またはI/Oパフォーマンスの改善に使用されます。
あなたの場合、より良いI/Oパフォーマンスを得ようとしていますか？
嫌悪感を指摘するのは嫌いですが、ウィキペディアは状況の適切な要約を提供します... http://en.wikipedia.org/wiki/Memory-mapped_file
具体的には...
メモリマップアプローチには、マイナーページフォールトのコストがあります。データのブロックがページキャッシュにロードされているが、プロセスの仮想メモリスペースにまだマップされていない場合です。状況によっては、メモリマップファイルI/Oは実際には標準のファイルI/Oよりかなり遅くなる場合があります。
スピードを早めに最適化しようとしているようです。なぜ通常のファイルアプローチではなく、必要に応じて後でMMファイルをリファクタリングしませんか？
両方のケースが関連していると思います。単一のチャンクを、メモリマッピングファイル内の適切な場所に、順番どおりに書き込むだけです。これは、bittorrentダウンローダーのように、各チャンクの場所を知っている場合にのみ役立ちます。チャンクがどこに行くべきかを知るために追加の分析を実行する必要がある場合、メモリマップファイルの利点はそれほど大きくないかもしれません。