GZIPOutputStream 与 BufferedOutputStream 的性能

Question

我的应用程序正在将大量视频和 i2c 传感器数据记录到磁盘文件中 - 尽可能快。目前，我正在将所有内容都转换为字节，并且正在使用 BufferedOutputStream 进行编写。 @Siguza 非常友好地建议研究 GZIPOutputStream 来完成任务。我想知道你是否对性能问题有任何想法赞成和反对......我认为处理器遥遥领先，磁盘写入是瓶颈 - 所以我希望在写入之前通过 GZIPOutputStream 进行动态压缩可能是一个很好的策略。非常欢迎对此提出任何想法。

添加：响应 cmets ...

事实证明，压缩并不是那么昂贵的处理器......而且我提出原始问题的方式并不好，正如 erwin 正确指出的那样。关于压缩性能的问题不在 BufferedOutputStream 和 GZIPOutputStream 之间......压缩和解压缩的流都需要包装到 BufferedOutputStream 中，但是如果原始 FileOutputStream 在它之前先包装在 GZIPOutputStream 中会增加多少成本包装在 BufferedOutputStream 中。这是答案。我正在使用代码

byte[] bs = RHUtilities.toByteArray((int)1);
boolean zipped = false;

FileOutputStream fos = new FileOutputStream(datFile);
BufferedOutputStream bos = null;
if (zipped) {
    GZIPOutputStream gz = new GZIPOutputStream(fos);
    bos = new BufferedOutputStream(gz);
} else 
    bos = new BufferedOutputStream(fos);
long startT = System.currentTimeMillis();
for (int i=0; i<1000000; i++)
    bos.write(bs);
bos.flush();
System.out.println(System.currentTimeMillis()-startT);
bos.close();

我的 2012 年 macpro 笔记本电脑使用

写入了 100 万个整数

zipped=true in 38ms - 文件大小 4MB
zipped=false in 21ms - fileSize 4KB

而且，是的，我喜欢压缩 :-)

读取性能几乎相同，分别为 83 毫秒和 86 毫秒

FileInputStream fin = new FileInputStream(datFile);

和

GZIPInputStream gin = new GZIPInputStream(new FileInputStream(datFile));

一切都好……

Answer 1

这个问题引发了很多问题：

我认为处理器遥遥领先，磁盘写入是瓶颈

“我在想”并不是优化性能的良好基础。您需要进行一些测量以找出瓶颈的实际位置。 （如果您的“想法”是错误的，那么更改为 GZipOutputStream 可能会使事情变得更糟。）

或者，只需尝试一下，然后衡量它是否会提高性能。

从理论上讲，如果处理器和磁盘速度之间存在严重不匹配，那么压缩可能会有所帮助。一个可能的好处是压缩还可以节省磁盘空间。

但缺点是：

• 压缩相对昂贵（解压缩也是如此），因此您最终可能会使用比通过减少 I/O 获得的更多（已用）时间
• 压缩对小文件无效，
• 与格式无关的压缩对原始（未压缩）音频或视频数据不是很有效¹
• 如果您的视频数据已经被压缩，那么第二次压缩将毫无效果。

最后，这可能是“大量小文件”的问题。如果您尝试读取和写入大量小文件，瓶颈可能不是原始磁盘速度。相反，它可能是操作系统读取和写入目录和/或文件元数据的能力。如果这就是您的问题所在，那么您应该考虑将“大量小文件”捆绑到档案中；例如TAR 或 ZIP 文件。在 Java 中有用于执行此操作的库。

存档的另一个好处是它们可以使压缩更有效。

---

^{1 - 对于背景，请阅读 https://en.wikipedia.org/wiki/Lossless_compression 和 https://en.wikipedia.org/wiki/List_of_codecs#Lossless_video_compression}