GZIPOutputStream 与 BufferedOutputStream 的性能对比

performance of GZIPOutputStream vs BufferedOutputStream

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

添加:回应评论...

事实证明,压缩并不是处理器的昂贵...而且我问最初问题的方式并不好,正如欧文正确指出的那样。关于压缩性能的问题不在 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 笔记本电脑使用

写入 1M 整数

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

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

读取性能几乎相同,83 与 86 毫秒之间

FileInputStream fin = new FileInputStream(datFile);

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

都很好...

这个问题提出了很多问题:

i am thinking the processor is way ahead and the disk write is the bottleneck

"I am thinking" 不是优化性能的可靠基础。您需要进行一些测量以找出瓶颈的实际位置。 (如果您的 "thinking" 是错误的,那么更改为 GZipOutputStream 可能会使事情变得更糟。)

或者,试试看,然后测量它是否提高了性能。

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

但缺点是:

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

最后,这可能是一个 "lots of small files" 问题。如果您尝试读取和写入大量小文件,瓶颈可能不是原始磁盘速度。相反,它很可能是 OS 读写目录 and/or 文件元数据的能力。如果那是您的问题所在,那么您应该考虑将 "lots of little files" 捆绑到档案中;例如TAR 或 ZIP 文件。在 Java.

中有用于执行此操作的库

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


1 - 对于背景,阅读 https://en.wikipedia.org/wiki/Lossless_compression and https://en.wikipedia.org/wiki/List_of_codecs#Lossless_video_compression