使用ZSTD_CCtxParams_setParameter(cctxParams, ZSTD_c_targetCBlockSize, ZSTD_TARGETCBLOCKSIZE_MAX)
会导致具有最小最小序列(> 1kB)的源极不可能发生坏的压缩。
使用缩小的CSS的重复连接:
设置targetCBlockSize == ZSTD_TARGETBLOCKSIZE_MAX时:
bootstrap.min.css : 97.31% (13862462 => 13488900 bytes, bootstrap.min.css.zst)
不设置targetCBlockSize:
bootstrap.min.css : 0.15% (13862462 => 20476 bytes, bootstrap.min.css.zst)
进一步的注意:我遇到此问题是因为尝试减小有关#2093的解压缩时的块大小。 如果减小ZSTD_BLOCKSIZEMAX本身而不是设置TargetCompressedBlockSize,进而减小最大块大小,则对压缩的影响要小得多。
所使用的源是通过以下顺序获得的:
rm bootstrap.min.css; wget https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css && for i in {1..5}; do cat bootstrap.min.css >> bootstrap_2.min.css; cat bootstrap_2.min.css >> bootstrap.min.css; done && rm bootstrap_2.min.css
我在这里要问有关体系结构的问题:targetCBlockSize是否会使压缩器假定它将被馈送到在其接收的块之外不知道任何信息的解压缩器中? 即它是一个完全无缓冲的流解压缩器?
targetCBlockSize
是“ meant”,用于要减少解压缩第一个字节的时间的流传输方案。 因此,如果数据包大小为4KB,则可以将目标块大小设置为4KB,并尝试使每个数据包都可解压缩,而不必在解压缩第一个字节之前等待完整的128KB。
我不确定在这种情况下会发生什么,但是通过输入,它应该很容易重现和修复。 我会尽快调查。 再次感谢您提供的报告和详细的复印说明!
@dciliske我已在22级上重现了该问题。zstd-1.4.4中不存在此问题,因此从未将其发布。 好像我在https://github.com/facebook/zstd/pull/1947中介绍了它
最有用的评论
@dciliske我已在22级上重现了该问题。zstd-1.4.4中不存在此问题,因此从未将其发布。 好像我在https://github.com/facebook/zstd/pull/1947中介绍了它