CPUの増加がしばらくディスク速度を上回ったようです。最新のデュアルコアIntel / AMD CPUと単一の平均SATAディスクを搭載したデスクトップまたはラップトップを想定すると、ほとんどすべてのディスクで圧縮を実行すると、全体的なパフォーマンスが向上しますか？基本的に、減少したディスク帯域幅は、増加したCPU負荷を補う以上のものですか？本当の答えは「それはあなたが何をしているのかによる」と確信しています。この質問をすることで、このパイプを実行した人がいて、例や落とし穴をいくつか示したいと思っています。
回答:
はい、ディスク圧縮は特定の状況下でより良いパフォーマンスを提供できます：
最近のグリーンフィールド設計であるZFSとBtrfsの両方に圧縮機能が含まれているのには理由があります。
HPC領域では、アプリケーションがメモリからディスクにチェックポイントを設定しているとき、CPUはほとんど何も役に立たないことがよくあります。この時間は本質的に純粋なオーバーヘッドです。この時間を短縮するためのCPUの使用はすべて勝利です。
ディスク圧縮によってパフォーマンスが向上することは決してありません。
最近の高速なCPUによるペナルティはほとんどないかもしれませんが、それはまったく異なります。
ディスクとの間で転送するデータを少なくすることで、パフォーマンスが向上すると想定しています。ただし、ビッグデータ転送がI / Oボトルネックになることはほとんどありません。実際のボトルネックは、シーク時間と待ち時間です。現代のハードディスクは、大きなファイルを使用した持続的なデータ転送で本当に高速です。低速になるのは、ディスク全体からの転送がほとんどないためです。
いくつかのシナリオ：
ビデオ圧縮など、すでにアプリケーションごとのレベルでこれを行う特定の状況があります-dskから未加工のHD品質のビデオを十分に速く読み込めなかったシステムは、代わりに圧縮された情報を読み取って、メモリとCPUパワーを使用して拡張できます。これが他の特定の状況にも当てはまらない理由はありませんが、これはアプリケーションレベルで最適に処理できるため、使用される圧縮方法は目的に合わせて最適化されます。
スループット全体が増加する場合、解凍のパフォーマンスオーバーヘッドは価値があるので、アイデアを手放さないようにする必要があることに注意してください-圧縮を向上させる汎用のパフォーマンス向上の準備はまだ整っていないと思いますが、理論的には可能です（CPUとメモリ）が過剰なリソースを他の場所でのブースト（ハードドライブから読み取ったデータの合計）と交換する
あなたはあなた自身の質問に答えました！それは確かに答えです。
私が作ることができる最良の一般化は：
ディスク読み取りが制限されているデータベースアプリケーションがある場合は、そうです！パフォーマンスが優れています。
これは、デスクトップ/ラップトップで行うほとんどのアクティビティには当てはまらないと思います。
私のドメイン（SQL Server）では、圧縮を使用すると、読み取り負荷が高いレポートデータベースでパフォーマンスが向上することを知っています。mysqlについても同様です。
Microsoftは、SQL Server 2008の圧縮機能に関するホワイトペーパーを持っています。DBAでない限り、正確な説明ではありませんが、私の一般化をサポートする1つのグラフを次に示します。
CPU速度は常にディスク速度よりも高速でした。私見、圧縮はオーバーヘッドを増加させ、それによってパフォーマンスを低下させます。
私は昨日、OSXについてこれに似たものを読んでいて、それはファイルシステムの圧縮です-基本的に答えは圧縮したいものを中心に展開しています-この例では、彼は「FAT」データについて話しています。ファイル構造、プロパティ、メタデータなどをまとめて保存すると、スペースを節約するために圧縮して、各ファイルのデータを見つけるためにあらゆる場所で頭を探すよりも速くCPUに読み込むことができます...
とにかく、あなたがそのようなことについて考えているなら、読む価値があります:-p
しかし、圧縮は単にディスク容量を節約するだけではありません。これは、I / Oレイテンシと帯域幅を削減するためにCPUサイクルをトレードする典型的な例でもあります。過去数十年の間に、CPUパフォーマンスはディスクパフォーマンスの増加よりもはるかに速い速度で向上しました（そしてコンピューティングリソースはさらに豊富になり、後で詳しく説明します）。最新のハードディスクシーク時間と回転遅延は、ミリ秒単位で測定されます。1ミリ秒で、2 GHz CPUは200万サイクルを通過します。そしてもちろん、考慮すべき実際のデータ転送時間はまだあります。
確かに、OSとハードウェア全体のいくつかのレベルのキャッシュは、これらの遅延を隠すために強力に機能します。しかし、それらのビットは、それらのキャッシュを満たすために、ある時点でディスクから外れる必要があります。圧縮とは、転送する必要があるビットが少なくなることを意味します。現代のマルチコアMacの通常の使用におけるほぼコミカルなCPUリソースの過大を考えると、圧縮されたペイロードをディスクから転送し、CPUを使用してその内容をメモリに解凍するのに必要な合計時間は、通常、時間よりもはるかに短くなります。非圧縮形式でデータを転送するには時間がかかります。
これにより、転送するデータが少なくなることによる潜在的なパフォーマンス上の利点が説明されますが、ファイルの内容を格納するために拡張属性を使用すると、実際に高速化することもできます。それはすべてデータの局所性に関係しています。
大量のデータを転送するよりもハードディスクの速度が低下する原因が1つある場合、それはディスクのある部分から別の部分にヘッドを移動しています。すべての移動とは、ヘッドが移動を開始してから停止し、目的の位置に正しく配置されていることを確認してから、回転するディスクが目的のビットをその下に置くのを待つ時間を意味します。これらはすべて実際の物理的な可動部分であり、彼らが彼らと同じくらい速くそして効率的に彼らのダンスをするのは驚くべきことですが、物理学には限界があります。これらのモーションは、ハードディスクなどの回転ストレージの真のパフォーマンスキラーです。
HFS +ボリューム形式は、ファイルに関するすべての情報（メタデータ）をディスク上の2つの主要な場所に格納します。ファイルの日付、権限、所有権、およびその他のホストを格納するカタログファイルと、「名前付きフォーク」を格納する属性ファイル」
HFS +の拡張属性は、属性ファイルで名前付きフォークとして実装されます。ただし、非常に大きくなる可能性がある（ファイルシステムでサポートされる最大ファイルサイズまで）リソースフォークとは異なり、HFS +の拡張属性は「インライン」で属性ファイルに格納されます。実際には、これは属性ごとに約128バイトの制限を意味します。ただし、実際のデータを取得するためにディスクヘッドがディスクの別の部分に移動する必要がないことも意味します。
ご想像のとおり、カタログファイルと属性ファイルを構成するディスクブロックは頻繁にアクセスされるため、ほとんどの場所でキャッシュ内にある可能性が高くなります。これらすべては、データのメタデータを含むファイルの完全なストレージをBツリー構造のカタログファイルと属性ファイル内に完全に格納することで、全体的なパフォーマンスを向上させます。25バイトに膨らむ8バイトのペイロードであっても、それが通常のデータストレージのアロケーションブロックサイズよりも小さく、すべてが属性ファイルのBツリーノード内に収まる限り、問題にはなりません。とにかく、OS全体を読み取る必要があります。
Snow Leopardのディスクフットプリントの削減には他にも大きな貢献があります（たとえば、不要なローカリゼーションと "designable.nib"ファイルの削除）が、HFS +圧縮は、技術的に最も興味深いものです。
送信元：http : //arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3
Microsoft Disk圧縮は醜い古いです。80年代のARJ法との比率ではほとんど比較できません。ただし、Microsoftの圧縮CANでも、非常に遅い（ラップトップ）ハードドライブでより優れたパフォーマンスを提供できます。特に、書き込みキャッシュと過剰な書き込みを防ぐのに十分なRAMがある場合。
書き込みプロセスは、ランダムアクセスが有効な圧縮方法の弱点です。
したがって、圧縮ドライブが必要な場合は、何らかのLinuxに移行することをお勧めします。
ディスク圧縮はRAMドライブにも非常に適しています。理由を説明する必要はありません。
間違いなく。圧縮と解凍には、ディスクとCPUだけではありません。特に、メモリとの間のデータの転送は（圧縮を行わない標準の転送オーバーヘッドに加えて）大量に発生し、ページフォールトの点で非常に悪影響を及ぼします。