Hex Workshop などの多くの 16 進エディタは、比較的小さなメモリ フットプリントを維持しながら、大きなサイズのファイルを読み取ることさえできますが、それでもスクロールをスムーズに保つことができます。これを達成するための最良の方法を探しているので、関連する質問がいくつかあります。
FileStream を使用する必要がありますか?
- バッファリングは現在のシーク位置に基づいていますか? (通常、逆方向にスクロールするとページフォールトになりますか?)
- 内部でのみ Seek を使用する FileStream のラッパーを作成すると、FileStream の適切なバッファリング機能が損なわれますか? (つまり、シークが近くにある場合でも、シークを繰り返すとパフォーマンスが大幅に低下しますか? パフォーマンスを維持するために、バッファリング アルゴリズムまたはディスク スケジューラを
利用できますか?) (私はおそらく100MBまでのファイルしか期待していません)
- 検索/ジャンプ/高速スクロールによるページ フォールトは、顕著なパフォーマンスの問題を引き起こしますか?
最終的に、データを表示する必要があります。ファイル全体をビットマップとしてレンダリングし、変更時に画像の一部を無効にする必要がありますか (スクロール コントロールが画像に対して独自のページングを実行できるようにする)、またはスクロール イベントで現在の表示領域を生成する必要がありますか?
要するに、データ、生成された画像、またはその両方をページングしますか、それとも必要に応じてそれらを取得/生成しますか? このタスクに最適な (WPF/.Net) ライブラリ/API オブジェクトは何ですか?
T.R.
質問する
407 次
2 に答える
2
あなたはすでに答えを持っているようです。
これに対する一般的な解決策は、メモリ マップ ファイルを使用し、OS にキャッシュとシークを任せることです。
最初に、最も単純で最も明白な解決策を試してください。満足のいく結果が得られない場合は、ボトルネックを最適化します。時期尚早の最適化は諸悪の根源です。
于 2009-03-29T10:19:57.667 に答える
1
100MBは実際にはそれほど大きくありません。したがって、メモリ内ではおそらく新しいマシンで動作します。
しかし、時間の経過とともにソリューションが拡張されないようにする必要はありません。制限が100MBであると想定した瞬間、誰かが200MBで試してみます。したがって、「シーク」ルートを使用することをお勧めします。これが一般的な方法です。
于 2009-03-29T06:43:59.683 に答える