GZIPOUTPUTSTREAM与BufferedOutputStream的性能

Question

我的应用程序正在将视频和i2c传感器数据记录到磁盘文件中 - 尽可能快。目前，我正在将所有内容转换为字节，并且正在使用BufferedOutputStream编写。@siguza非常友善，可以建议您研究GZIPOUTPUTSTREAM来完成契约。我想知道您是否对绩效问题和骗局有任何想法...我认为处理器正在前进，并且磁盘写入是瓶颈 - 所以我希望在写入之前，通过gzipoutputstream即时进行压缩一个好的策略。对此的任何想法都非常受欢迎。

添加：响应评论...

事实证明，拉链并不是那个处理器昂贵的...正如欧文正确指出的那样，我问的原始问题的方式并不好。关于拉链性能的问题不在bufferedOutputstream和gzipoutputstream之间... zippert和未拉链的流都需要包装到bufferedOutputstream中，但是如果原始的fileOutputStream首先包裹在gzipoutputStream中，则添加了多少成本包裹在一个缓冲的图像中。这是答案。我正在使用代码

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 int的写作

zipped = true 38ms -Filesize 4MB
zipped = false in 21ms- filesize 4kb

，是的，我喜欢压缩： - ）

阅读灌注几乎相同83 vs 86ms

FileInputStream fin = new FileInputStream(datFile);

和

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

都很好...

Answer 1

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

我认为处理器处于领先地位，并且磁盘写入是瓶颈

"我在想"不是优化性能的合理基础。您需要进行一些测量，以找出瓶颈实际上在哪里。（如果您的"思考"是错误的，那么更改为gzipoutputstream很容易使事情变得更糟。）

另外，只需尝试一下，测量它是否改善了性能。

从理论的角度来看，如果处理器和圆盘速度之间存在显着的不匹配，则压缩可能会有所帮助。一个可能的好处是，压缩也可以节省磁盘空间。

但缺点是：

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

最后，这可能是一个"很多小文件"问题。如果您尝试读取很多小文件，则瓶颈可能不是原始磁盘速度。相反，它很可能是OS读写目录和/或文件元数据的能力。如果那是您的问题所在，那么您应该考虑将"很多小文件"捆绑到档案中；例如焦油或zip文件。有库在Java中进行此操作。

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

---

^{1-对于背景，请阅读https：//en.wikipedia.org/wiki/wiki/lossless_compression和https://en.wikipedia.org/wiki/wiki/wiki/list_of_codecs#lossless_video_video_video_compression}

/div>