大量のメモリを使用せずに大容量のファイルを表示する最も良い方法は何ですか？

Question

Hex Workshopなどの多くのヘキサエディタでは、メモリフットプリントは比較的小さくても大容量のファイルを読み取ることができますが、スクロールをスムーズに保ちます。私はこれを達成するための最善の方法を探しているので、いくつかの関連する質問があります。

私はFileStreamを使うべきですか？
    - バッファリングは現在のSeekの場所に基づいていますか？ （逆方向にスクロールすると通常はページフォールトですか？）     - Seekを内部的にしか使用しないFileStream用のラッパーを作成すると、正しくバッファリングするFileStreamの機能が損なわれますか？バッファリングアルゴリズムまたはディスクスケジューラを使用してパフォーマンスを向上させることはできますか？）

メモリマップ型I/Oを使用する方がよいでしょうか？ （私は実際には100MBまでのファイルしか期待していません）
    - 検索/ジャンプ/高速スクロールのpagefaultは顕著なパフォーマンスの問題を作りますか？

最終的には、データを表示する必要があります。ファイル全体をビットマップとしてレンダリングし、変更時にイメージの一部を無効にするか（スクロールコントロールがイメージ上で独自のページングを行うようにするか）、スクロールイベントで現在の表示領域を生成するだけですか？

Shortでは、データ、生成されたイメージ、またはその両方をページングするか、必要に応じてページを取得/生成しますか？このタスクに最も適した（WPF/.Net）ライブラリ/ APIオブジェクトは何ですか？

Answer 1

すでに答えがあるようです。
この一般的な解決策は、Memory Mapped filesを使用し、OSにキャッシングとシークを気にさせます。
まず、最も単純で最も明白な解決策を試してください。それが満足のいくものでなければ、ボトルネックを最適化してください。 Premature optimizations is the root of all evil.

Answer 2

実際にはそれほど大きくありません。だからメモリはおそらく新しいマシンで動作します。

しかし、時間が経つにつれてソリューションの規模が拡大しないようにすることは望ましくありません。あなたが限界を100MBと仮定した分、誰かがそれを200MBで試みます。だから私はあなたが "シーク"ルートを取ることをお勧めしたい - それはそれを行う一般的な方法です。