如何解决无需冲洗即可估算DEFLATEzlib当前压缩大小的方法
我目前正在编写一个程序,该程序使用高速缓存行(64字节,但可调整),并尝试将尽可能多的内容装入512字节块(再次可调)。
问题在于,在每次不放气进行放气的调用之后,我至少需要能够对当前压缩大小进行至少一个粗略的估计。每个字节对于我的目的都很重要,并且刷新会根据数据增加非常大的开销,特别是考虑到我正在使用的小块大小。我已经尝试过使用Z_SYNC_FLUSH和Z_PARTIAL_FLUSH进行各种不同的实现,但是它们都增加了很多开销,因此始终是有用的。
我当前的幼稚方法是压缩9个高速缓存行(576字节),并检查它是否适合512块,如果是,则添加另一个高速缓存行并重新压缩整个缓冲区,依此类推。如果前9个缓存行无法放入512块中,则它只是未压缩存储(原始未压缩)。
您可以想象这种方法要花很长时间,用这个方法压缩一个7gb的文件花了将近3个小时。
我注意到z_stream结构具有我可以公开的内部状态,但是我没有找到任何明显的方法来利用它来获取估计值。我认为这是因为直到刷新为止,实际上没有压缩。
在进行实际冲洗之前,是否总会得到压缩输出的估计大小? 如果没有,我有什么办法可以减少当前方法的时间开销?
解决方法
看看fitblk.c的一种方法。它的开销约为3倍,因为每个块进行3次压缩。
基本思想是首先进行压缩,以充分填充所需的块。然后解压缩,直到处理了适合所需块的压缩数据量,然后仅对其进行压缩。在第二次通过可以完善拟合。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。