NTFS圧縮はパフォーマンスにどのように影響しますか？
NTFS圧縮は余分なCPU使用によりパフォーマンスを低下させる可能性があると聞いたことがありますが、ディスクの読み取りが減少するため、実際にはパフォーマンスが向上する可能性があるという報告を読んでいます。 NTFS圧縮はシステムパフォーマンスにどの程度正確に影響しますか？
ノート：
- 私は5400 RPMのハードドライブを搭載したラップトップを実行しており、その上で私が行うことの多くはI/Oバウンドです。
- プロセッサは、2.0 GHzで動作する4つのコアを備えたAMD Phenom IIです。
- システムは ltraDefrag を使用して定期的に最適化されます。
- ワークロードは読み取りと書き込みが混在しており、読み取りは書き込みよりもやや頻繁に発生します。
- 圧縮するファイルには、選択した個人ドキュメント（完全なホームフォルダーではない）のサブセットと、いくつかの（それほど要求が厳しくない）ゲームやVisual Studio（I/Oが多くなる傾向がある）を含むプログラムが含まれます。
NTFS圧縮は余分なCPU使用によりパフォーマンスを低下させる可能性があると聞いたことがありますが、ディスクの読み取りが減少するため、実際にはパフォーマンスが向上する可能性があるというレポートを読みました。
正しい。 CPUが何らかの圧縮アルゴリズムを使用して、C MB /秒で圧縮し、D MB /秒で解凍できると仮定します。ハードドライブの書き込み速度はWで、読み取り速度はRです。C> Wである限り、次の場合にパフォーマンスが向上します。書き込み、およびD> Rである限り、読み取り時にパフォーマンスが向上します。 Lempel-Zivのアルゴリズム（ソフトウェアに実装されている）は非決定論的な圧縮率を持っているため（これは限られた辞書サイズで制約される可能性があります）、これは書き込みの場合の抜本的な仮定です。
NTFS圧縮はシステムパフォーマンスにどの程度正確に影響しますか？
まあ、それはまさに上記の不等式に依存することによるものです。 CPUがHDD書き込み速度を超える圧縮/解凍率を維持できる限り、速度が向上するはずです。ただし、これは大きなサイズのファイルに影響を及ぼし、（アルゴリズムにより）フラグメンテーションが激しくなったり、 まったく圧縮されない になる可能性があります。
これは、圧縮が進むにつれてLempel-Zivアルゴリズムの速度が低下するという事実が原因である可能性があります（ディクショナリが増加し続け、ビットが入るにつれてより多くの比較が必要になるため）。 Lempel-Zivアルゴリズムでは、ファイルサイズに関係なく、解凍はほぼ常に同じレートです（辞書はbase + offsetスキームを使用してアドレス指定できるため）。
圧縮は、ファイルの状態にも影響します ディスク上に配置されます 。デフォルトでは、単一の「圧縮単位」はクラスターのサイズの16倍です（そのため、ほとんどの4 kBクラスターNTFSファイルシステムは、ファイルを格納するために64 kBのチャンクを必要とします）が、64 kBを超えて増加することはありません。ただし、これは断片化とディスク上のスペース要件に影響を与える可能性があります。
最後の注意点として、遅延は議論のもう1つの興味深い価値です。データの圧縮にかかる実際の時間はレイテンシをもたらしますが、CPUクロック速度がギガヘルツ（つまり、各クロックサイクルが1 ns未満）の場合、ハードドライブシークレート（ミリ秒のオーダー、または数百万のクロックサイクル）。
実際に速度が向上するかどうかを確認するには、いくつか試すことができます。 1つ目は、Lempel-Zivベースの圧縮/解凍アルゴリズムを使用してシステムをベンチマークすることです。良い結果が得られた場合（C> WおよびD> R）、ディスクの圧縮を有効にしてみてください。
そこから、実際のハードドライブのパフォーマンスについてより多くのベンチマークを実行したい場合があります。 （あなたの場合）本当に重要なベンチマークは、ゲームの読み込み速度と、Visual Studioプロジェクトのコンパイル速度を確認することです。
TL、DR：高スループットと低レイテンシを必要とする多くの小さなファイルを利用するファイルシステムでは、圧縮可能性があります。大きなファイルは、パフォーマンスと遅延の問題により影響を受けません（影響を受けません）。
あなたはかなり遅いディスクを持っているので、あなたの質問にはメリットがあります。 NTFS圧縮はプロセッサを集中的に使用し、圧縮効率ではなく速度に合わせて調整されます。
読み取り操作が（非常に）少し改善されることを期待しています。ただし、システムキャッシュにあるファイルにアクセスする場合は、アクセスするたびに再度圧縮解除する必要があるため、パフォーマンスが低下します。
もちろん、追加の圧縮のために書き込み操作が遅くなることがわかります。
この同じNTFSディスクにファイルをコピーするには、解凍と圧縮が必要なため、これらのファイルが最も影響を受けます。
NTFS圧縮は断片化を大幅に増加させる可能性もありますが、これは「標準的な」作業負荷がかかっているほとんどの「標準的な」コンピュータでは問題になりません。
JPEG画像、ビデオ、.Zipファイルなど、多くの種類のファイルは基本的に圧縮できないため、これらのファイルは使用に時間がかかり、スペースを節約できません。
1つのディスククラスター（通常は4K）より小さいファイルは、ゲインがないため圧縮されません。ただし、ボリューム全体を圧縮する場合は、クラスターサイズをさらに小さくすることをお勧めします。
NTFS圧縮は、比較的静的なボリュームまたはファイルに推奨されます。システムファイルやUsersフォルダーには推奨されません。
ただし、ハードウェア構成はコンピューターモデルによって異なり、ディスク、バス、RAMおよびCPUによって異なるため、テストによって圧縮がコンピューターモデルにどのような影響を与えるかがわかります。
NTFSのWikpediaエントリで説明しました。
NTFSは、LZNT1アルゴリズム（LZ77の変形[23]）を使用してファイルを圧縮できます。ファイルは16クラスターのチャンクに圧縮されています。 4 kBクラスターでは、ファイルは64 kBのチャンクに圧縮されます。圧縮によって64 kBのデータが60 kB以下に削減される場合、NTFSは不要な4 kBページを空のスパースファイルクラスターのように扱います-それらは書き込まれません。これにより、無理のないランダムアクセス時間が可能になります。ただし、64 kBのチャンクごとに小さなフラグメントになるため、大きな圧縮可能なファイルは非常に断片化されます。 [24] [25]パフォーマンスが低下するため、Microsoftは30 MBを超えるファイルの圧縮を推奨していません。[引用が必要]
圧縮の最適な使用法は、繰り返し行われることはほとんどなく、通常は順次アクセスされるファイルで、それ自体は圧縮されないファイルです。ログファイルは理想的な例です。 4 kB未満のファイルまたは既に圧縮されているファイル（.Zip、.jpg、.aviなど）を圧縮すると、ファイルのサイズが大きくなるだけでなく、速度が遅くなる場合があります。 4 kBページでページインおよびページアウトされます）。ドライバ、NTLDR、winload.exe、またはBOOTMGRなどの起動時に使用されるシステムファイルを圧縮すると、システムが正しく起動しない場合があります。
圧縮ファイルへの読み取り/書き込みアクセスは、多くの場合（27）透過的ではありませんが、プロセッサにかなりの負荷をかけるため、ローミングプロファイルを保持するサーバーシステムやネットワーク共有での圧縮は避けることをお勧めします。[28]
ハードディスクの容量が限られているシングルユーザーシステムでは、圧縮率に応じて、4 kBから64 kB以上の小さなファイルに対してNTFS圧縮を利用できます。 900バイト未満のファイルは、ディレクトリエントリと共にMFTに格納されます。[29]
コンピューターで最も遅いリンクはCPUではなくハードドライブの速度であるため、NTFS圧縮により、容量と（多くの場合）速度の両方の観点から、制限された低速のストレージ領域をより適切に使用できます。 （これは、圧縮ファイルのフラグメントが連続して格納されることを前提としています。）
64KB以下（1個）に圧縮されるファイルのみを圧縮することをお勧めします。それ以外の場合、ファイルは64K以下の小数で構成されます。
MyDefragは、デフラグのより良い仕事をします。
操作が遅くなります。残念ながら、システムへの影響の程度を正確に測定することはできません。圧縮されたファイルが開かれると、システムが使用できるようにファイルを解凍するのにプロセッサの能力が必要になります。それを使い終わって[保存]をクリックすると、より多くのプロセッサ能力を使用して再度圧縮します。ただし、パフォーマンスを測定できるのはあなただけです。