在现代系统上，使用磁盘压缩会给我更好的整体性能吗？

是的，磁盘压缩可以在特定情况下提供更好的性能：

• 您的应用程序受磁盘吞吐量限制：现代 CPU 和（解）压缩算法可以在长传输中以比现代磁盘更高的带宽运行。在这种情况下，任何减少移入或移出磁盘盘片的数据量都是一种胜利
• 与传输时间的差异相比，（解）压缩到磁盘盘片的数据所需的时间更少，并且您有空闲的 CPU 周期

ZFS 和 Btrfs 都是最近的绿地设计，都包含压缩规定是有原因的。

在 HPC 空间中，当应用程序从内存检查点到磁盘时，CPU 通常根本不做任何有用的事情。这次基本上是纯粹的开销。任何使用 CPU 来减少此时间都是一种胜利。

磁盘压缩永远不会给你更好的性能。

由于快速的现代 CPU，它可能几乎不会给您带来任何损失，但这是完全不同的事情。

您假设必须从/向磁盘传输更少的数据可以提高性能；但大数据传输几乎从来都不是 I/O 瓶颈：真正的瓶颈是寻道时间和延迟。现代硬盘在大文件的持续数据传输上非常快，而减慢它们的速度是来自整个磁盘的少量传输。

一些场景：

• 媒体文件。这些通常已经自行压缩（JPEG、MPEG、MP3），因此在文件系统级别压缩它们根本没有帮助；相反，它会使事情变得更糟，因为已经需要 CPU 资源来编码/解码它们。
• 数据库。这些通常是在很小的随机突发中读取/写入的，因此压缩它们不仅没有任何好处，而且还会降低性能，因为 DBMS 无法正确识别它需要访问的物理数据在磁盘上的位置是存储。
• 页面文件。这通常非常大，但操作系统需要处理非常小的数据块，并且需要非常精确地执行此操作（“在物理地址 X 处读取 4K”）；压缩它通常是不可能的，但即使是这样，也将完全浪费时间和资源：由于该文件的“完全随机数据”性质，它将提供几乎零压缩。

有些特定情况已经在每个应用程序级别执行此操作，例如视频压缩 - 无法从 dsk 以足够快的速度读取原始高清质量视频的系统可以改为读取压缩信息并使用内存和 CPU 能力对其进行扩展. 没有理由在其他特定情况下也不会出现这种情况，但这可以在应用程序级别得到最好的处理，因此使用的压缩方法针对其目的进行了优化。

请记住，如果整个吞吐量增加，解压缩的性能开销是值得的，所以这个想法不应该被忽视——我认为我们还没有准备好通用性能提升压缩，但理论上是可能的用你拥有的资源（CPU和内存）换取其他地方的提升（从硬盘读取的总数据）

你是在自问自答！这取决于确实是答案。

我能做的最好的概括是：

如果您有一个磁盘读取受限的数据库应用程序，那么可以！性能更好。

我认为您将在台式机/笔记本电脑上进行的大多数活动都不是这种情况。

在我的域（SQL Server）中，我知道如果使用压缩，在重读负载下的报告数据库可以获得更好的性能。我知道 mysql 也是如此。

Microsoft 有一份关于 SQL Server 2008 中压缩功能的白皮书。除非您是 DBA，否则阅读量并不大，但这里有一张图表支持我的概括：

CPU 速度一直快于磁盘速度。恕我直言，压缩会增加开销，从而降低性能。

我昨天正在阅读与 OSX 类似的东西，它是文件系统的压缩——基本上答案围绕着你想要压缩的内容——在这个例子中，他谈论的是“FAT”数据；文件结构、属性、元数据等存储在一起时可以被压缩以节省空间，并且比到处寻找头来查找每个文件的数据更快地读入 cpu...

无论如何，如果您正在考虑这些事情，值得一读：-p

但压缩不仅仅是为了节省磁盘空间。这也是一个用 CPU 周期来降低 I/O 延迟和带宽的经典示例。在过去的几十年里，CPU 性能变得更好（计算资源更丰富——稍后会更多），其速度远快于磁盘性能的增长速度。现代硬盘寻道时间和旋转延迟仍然以毫秒为单位。在一毫秒内，一个 2 GHz CPU 经历了 200 万个周期。然后，当然，还有实际的数据传输时间需要考虑。

诚然，整个操作系统和硬件的多个级别的缓存可以有效地隐藏这些延迟。但是这些位必须在某个时候从磁盘上取下来填充这些缓存。压缩意味着必须传输的位更少。考虑到现代多核 Mac 在正常使用情况下 CPU 资源几乎可笑的过剩，从磁盘传输压缩的有效负载并使用 CPU 将其内容解压缩到内存所需的总时间通常仍远少于时间它需要以未压缩的形式传输数据。

这解释了传输较少数据的潜在性能优势，但使用扩展属性来存储文件内容实际上也可以使事情变得更快。这一切都与数据局部性有关。

如果有一件事情比传输大量数据更能减慢硬盘的速度，那就是它的磁头从磁盘的一个部分移动到另一个部分。每一次移动都意味着磁头开始移动，然后停止，然后确保它正确定位在所需位置上，然后等待旋转磁盘将所需位放在其下方。这些都是真实的、物理的、移动的部分，令人惊讶的是，它们能像他们一样快速有效地跳舞，但物理学有其局限性。这些动作是硬盘等旋转存储的真正性能杀手。

HFS+ 卷格式将有关文件的所有信息（元数据）存储在磁盘上的两个主要位置：目录文件，它存储文件日期、权限、所有权和许多其他内容，以及属性文件，它存储“命名分叉” 。”

HFS+ 中的扩展属性作为属性文件中的命名分支实现。但与可能非常大的资源分叉不同（达到文件系统支持的最大文件大小），HFS+ 中的扩展属性被“内联”存储在属性文件中。实际上，这意味着每个属性的限制约为 128 个字节。但这也意味着磁头不需要到磁盘的另一部分去获取实际数据。

可以想象，构成目录和属性文件的磁盘块经常被访问，因此比大多数磁盘块更有可能在某个地方的缓存中。所有这些共同使文件的完整存储（包括其数据中的元数据）在 B 树结构的目录和属性文件中获得整体性能优势。即使是膨胀到 25 字节的 8 字节有效负载也不是问题，只要它仍然小于正常数据存储的分配块大小，并且只要它都适合属性文件中的 B 树节点无论如何，操作系统必须完整阅读。

Snow Leopard 减少磁盘占用空间还有其他重要贡献（例如，删除不必要的本地化和“designable.nib”文件），但 HFS+ 压缩是迄今为止技术上最有趣的。

来自： http ://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3

Microsoft 磁盘压缩是丑陋的 OLD。与 80 年代的 ARJ 方法的比率几乎无法比拟。但是，即使是 Microsoft 的压缩也可以在非常慢的（笔记本电脑）硬盘上提供更好的性能。特别是如果有足够的 RAM 用于写入缓存并防止过度写入。

写入过程是任何启用随机访问的压缩方法的弱点。

所以，如果你想要压缩驱动器，你最好转向某种 Linux。

磁盘压缩也非常适合 RAM 驱动器，无需告诉你为什么。

怀疑。压缩和解压不仅仅涉及磁盘和CPU；特别是会有大量的数据进出内存的传输（除了没有压缩的标准传输开销），这在页面错误方面确实会受到伤害。

简而言之，不，您可能不会提高性能。

虽然压缩会提高存储性能，但会显着降低处理器速度。这可能归结为您要解压缩的文件类型。如果您只处理 word、excel 和其他基本文件类型，请继续压缩它们。如果单个文件更大，您将牺牲更多时间。