6

64ビットプロセス内でC＃コードを実行するAzureの役割で、ZIPファイルをダウンロードしてできるだけ早く解凍したいと思います。次のことができると思いました。MemoryStreamインスタンスを作成しMemoryStream、そこにダウンロードしてから、ストリームをZIP処理ライブラリに渡して解凍し、解凍が完了したらストリームを破棄します。このようにして、多くのI/Oを不必要に実行する書き込み-読み取り-書き込みシーケンスを取り除くことができます。

MemoryStreamただし、配列に裏打ちされた0.5ギガバイトの配列は、間違いなく「ラージオブジェクト」と見なされ、ガベージコレクションで圧縮されないラージオブジェクトヒープに割り当てられることを読みました。これは、おそらくこの使用法がMemoryStreamプロセスメモリの断片化と長期的な悪影響につながるのではないかと心配しています。

これは私のプロセスに長期的な悪影響を与える可能性がありますか？

4

1 に答える 1

1

答えは、あなたがリンクした質問に対する受け入れられた答えにあります。参照を提供していただきありがとうございます。

本当の問題は、プログラムがいつでもすべての仮想メモリを消費できるようにする必要があると想定していることです。64ビットオペレーティングシステムでコードを実行するだけで完全に解消される問題。

これが64ビットプロセスの場合、心配する必要はありません。

作成されたホールは、LOHの仮想アドレス空間の断片化につながるだけです。ここでの断片化はあなたにとって大きな問題ではありません。64ビットプロセスでは、断片化のために無駄になったページ全体が未使用になり、マップされた物理メモリが再び使用可能になり、新しいページをマップできます。これらは大きな割り当てであるため、無駄になる部分的なページはほとんどありません。また、参照の局所性（デフラグのもう1つの利点）はほとんど保持されます。これも、これらが大きな割り当てであるためです。

于 2012-08-09T11:35:23.663 に答える