在现代系统上，可以通过压缩输出流来提高本地硬盘写入速度吗？
这个问题源于我正在处理的一个案例，其中一个程序连续生成大约 1-2GB 的文本记录数据并将其转储到硬盘上的原始文本文件中，我认为它是 IO 绑定的。我是否希望能够通过在数据进入磁盘之前对其进行压缩来减少运行时间，或者压缩的开销是否会耗尽我可以获得的任何收益？有一个空闲的第二个核心会影响这个吗？
我知道这会受到用于生成数据的 CPU 数量的影响，因此关于需要多少空闲 CPU 时间的经验法则会很好。
我记得一个视频演讲，有人使用压缩来提高数据库的读取速度，但 IIRC 压缩比解压缩更占用 CPU 资源。
是的，是的，是的，绝对的。
以这种方式看待它：以每秒兆字节为单位获取最大连续磁盘写入速度。（继续测量它，为一个巨大的 fwrite 计时或其他东西。）假设是 100mb/s。现在以兆赫为单位计算您的 CPU 速度；假设 3Ghz = 3000mhz。将 CPU 速度除以磁盘写入速度。这是 CPU 空闲的周期数，您可以将每个字节用于压缩。在这种情况下，3000/100 = 每字节 30 个周期。
如果您有一种算法可以将数据压缩 25% 以实现 125mb/s 的有效写入速度，那么您将有 24 个周期来运行它，并且它基本上是免费的，因为 CPU 无论如何都不会做任何其他事情在等待磁盘搅动时。每字节 24 个周期 = 每 128 字节高速缓存行 3072 个周期，很容易实现。
我们在阅读光学媒体时一直这样做。
如果你有一个空闲的第二个核心，那就更容易了。只需将日志缓冲区移交给该内核的线程，它可能需要尽可能长的时间来压缩数据，因为它没有做任何其他事情！唯一棘手的一点是您实际上希望拥有一圈缓冲区，这样您就不会让生产者线程（制作日志的线程）在互斥锁上等待消费者线程（将其写入磁盘的缓冲区）持有。
是的，至少 10 年来都是如此。有关于它的操作系统论文。我认为 Chris Small 可能已经对其中一些进行了研究。
对于速度，较低质量级别的gzip/zlib压缩非常快；如果这还不够快，您可以尝试FastLZ。使用额外内核的一种快速方法就是popen(3)使用gzip.
值得一提的是，Sun 的文件系统 ZFS 能够启用动态压缩以减少磁盘 IO 的数量，而不会显着增加开销作为实践中的示例。
Stony Brook的文件系统和存储实验室在今年IBM 的 SYSTOR 系统研究会议上发表了关于服务器系统上文件数据压缩的相当广泛的性能（和能量）评估： ACM 数字图书馆的论文，演示文稿。
结果取决于
例如，在论文的测量中，使用文本工作负载和使用lzop 的服务器环境以低压缩量比普通写入更快，但 bzip 和 gz 不是。
在您的特定设置中，您应该尝试并测量。它确实可能会提高性能，但并非总是如此。
CPU 的增长速度比硬盘访问速度更快。甚至早在 80 年代，就可以从磁盘上读取许多压缩文件并在比读取原始（未压缩）文件所需的时间更短的时间内解压缩。那不会改变。
不过，一般来说，现在压缩/解压缩的处理级别比您编写的级别要低，例如在数据库 I/O 层中。
至于第二个内核的有用性，只有在系统还将执行大量其他事情时才重要——并且您的程序必须是多线程的才能利用额外的 CPU。
以二进制形式记录数据可能是一个快速的改进。您将减少对磁盘的写入，CPU 将花费更少的时间将数字转换为文本。如果人们要阅读日志，它可能没有用，但他们也无法阅读压缩日志。
Windows 已经支持 NTFS 中的文件压缩，因此您所要做的就是在文件属性中设置“压缩”标志。然后，您可以衡量它是否值得。
如果只是文本，那么压缩肯定会有所帮助。只需选择一种压缩算法和设置，使压缩成本低廉。“gzip”比“bzip2”便宜，并且两者都有参数，您可以调整以提高速度或压缩比。
这取决于很多因素，我认为没有一个正确的答案。归结为：
考虑到您可用于此目的的 CPU 带宽，您能否以比磁盘的原始写入性能乘以您正在实现的压缩率（或您尝试获得的速度倍数）更快的速度压缩原始数据？
鉴于当今相对较高的数据写入速率（10 兆字节/秒），这是一个相当高的障碍。就其他一些答案而言，您可能必须拥有易于压缩的数据，并且只需要通过一些合理性类型的实验测试来对其进行基准测试并找出答案。
相对于特定意见（猜！？）到关于额外核心的观点。如果您将数据压缩线程化并保持内核馈送 - 文本的高压缩率，那么这种技术很可能会取得一些成果。但这只是一个猜测。在磁盘写入和压缩操作之间交替的单线程应用程序中，对我来说似乎不太可能。
如果您受 I/O 限制，将人类可读的文本保存到硬盘驱动器，我希望压缩能够减少您的总运行时间。
如果您有一个空闲的 2 GHz 内核和一个相对较快的 100 MB/s 流式硬盘驱动器，则将净记录时间减半需要至少 2:1 压缩，并且每个未压缩字节不超过大约 10 个 CPU 周期，以便压缩器考虑数据。使用双管道处理器，每字节（非常粗略）20 条指令。
我看到 LZRW1-A（最快的压缩算法之一）每个字节使用 10 到 20 条指令，并以大约 2:1 的比例压缩典型的英文文本。在高端（每字节 20 条指令），您正处于 IO 限制和 CPU 限制之间的边缘。在中端和低端，您仍然受 IO 限制，因此有几个周期（不多）可用于稍微复杂一点的压缩器来更长时间地思考数据。
如果您有一个更典型的非顶级硬盘驱动器，或者由于某些其他原因（碎片、其他使用磁盘的多任务处理等）硬盘驱动器速度较慢，那么您有更多的时间来获得更多复杂的压缩器来思考数据。
您可能会考虑设置一个压缩分区，将数据保存到该分区（让设备驱动程序对其进行压缩），并将速度与您的原始速度进行比较。与更改程序和在压缩算法中链接相比，这可能需要更少的时间并且不太可能引入新的错误。
我看到一个基于 FUSE 的压缩文件系统列表，听说 NTFS 也支持压缩分区。
如果这台特定的机器经常受 IO 限制，另一种加快速度的方法是安装 RAID 阵列。这将为每个程序和每种数据（甚至是不可压缩的数据）提供加速。
例如，共有 4 个磁盘的流行 RAID 1+0 配置可提供近 2 倍的加速。
几乎同样流行的 RAID 5 配置，总共有 4 个磁盘，使所有速度提高了近 3 倍。
设置速度是单个驱动器速度 8 倍的 RAID 阵列相对简单。
另一方面，高压缩比显然不是那么简单。将“仅”6.30 压缩为 1 将为您提供现金奖励，以打破当前的压缩世界纪录（Hutter 奖）。
这曾经是可以在很多应用程序中提高性能的东西。我猜今天它不太可能得到回报，但它可能在你的特定情况下，特别是如果你记录的数据很容易压缩，
然而，正如 Shog9 所说：
经验法则在这里对您没有帮助。它是您的磁盘、您的 CPU 和您的数据。设置一个测试用例，并在压缩和不压缩的情况下测量吞吐量和 CPU 负载 - 看看是否值得权衡。