zlib编程中,CHUNK大小会影响压缩后的文件大小吗?
In zlib programming, will the CHUNK size affect the compressed file size?
我在Linux 平台上使用C 编程语言。
我参考了zlib官网(http://www.zlib.net/zlib_how.html)上的zlib使用示例,写了一个压缩程序。注意我的压缩方式是gzip,也就是说使用deflateint2()函数而不是deflateinit()。
根据 zlib 的网站,“CHUNK 只是用于向 zlib 例程提供数据和从中提取数据的缓冲区大小。更大的缓冲区大小会更有效,尤其是对于 inflate()。如果内存可用,缓冲区应该使用128K或256K字节左右的大小。”所以我认为CHUNK越大,压缩文件越小,压缩速度越快。
但是当我测试我的程序时,我发现无论CHUNK大小是16384还是1,压缩后的文件大小都是一样的(16384是zlib官方例程给出的典型值)。不同的是当chunk size为1时,压缩速度会慢很多。
这个结果让我很疑惑。我认为当CHUNK size为1时,压缩处理无效。因为在这个例程中,每个输入的CHUNK都会被处理并直接输出到一个压缩文件中,我认为1个字节的数据是不能压缩的。
所以我的问题是,为什么CHUNK大小只影响压缩速度,而不影响压缩率?
这是我的程序:
#define CHUNK 16384
int def(FILE *source, FILE *dest, int level, int memLevel)
{
int ret, flush;
unsigned have;
z_stream strm;
unsigned char in[CHUNK];
unsigned char out[CHUNK];
/* allocate deflate state */
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
ret = deflateInit2(&strm, level, Z_DEFLATED, MAX_WBITS + 16, memLevel, Z_DEFAULT_STRATEGY);
if (ret != Z_OK)
return ret;
/* compress until end of file */
do {
strm.avail_in = fread(in, 1, CHUNK, source);
if (ferror(source)) {
(void)deflateEnd(&strm);
return Z_ERRNO;
}
flush = feof(source) ? Z_FINISH : Z_NO_FLUSH;
strm.next_in = in;
/* run deflate() on input until output buffer not full, finish
compression if all of source has been read in */
do {
strm.avail_out = CHUNK;
strm.next_out = out;
ret = deflate(&strm, flush); /* no bad return value */
assert(ret != Z_STREAM_ERROR); /* state not clobbered */
have = CHUNK - strm.avail_out;
if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
(void)deflateEnd(&strm);
return Z_ERRNO;
}
} while (strm.avail_out == 0);
assert(strm.avail_in == 0); /* all input will be used */
/* done when last data in file processed */
} while (flush != Z_FINISH);
assert(ret == Z_STREAM_END); /* stream will be complete */
/* clean up and return */
(void)deflateEnd(&strm);
return Z_OK;
}
因为 deflate 在内部缓冲数据以进行压缩。无论您如何提供数据以放气,它都会累积并压缩字节,直到它有足够的空间来发出放气块。
你说得对,你不能压缩一个字节。如果你想看看这是多么真实,然后将 flush
从 Z_NO_FLUSH
更改为 Z_FULL_FLUSH
然后一次给它一个字节。然后确实 deflate 会尝试分别压缩输入的每个字节。
我在Linux 平台上使用C 编程语言。 我参考了zlib官网(http://www.zlib.net/zlib_how.html)上的zlib使用示例,写了一个压缩程序。注意我的压缩方式是gzip,也就是说使用deflateint2()函数而不是deflateinit()。
根据 zlib 的网站,“CHUNK 只是用于向 zlib 例程提供数据和从中提取数据的缓冲区大小。更大的缓冲区大小会更有效,尤其是对于 inflate()。如果内存可用,缓冲区应该使用128K或256K字节左右的大小。”所以我认为CHUNK越大,压缩文件越小,压缩速度越快。
但是当我测试我的程序时,我发现无论CHUNK大小是16384还是1,压缩后的文件大小都是一样的(16384是zlib官方例程给出的典型值)。不同的是当chunk size为1时,压缩速度会慢很多。
这个结果让我很疑惑。我认为当CHUNK size为1时,压缩处理无效。因为在这个例程中,每个输入的CHUNK都会被处理并直接输出到一个压缩文件中,我认为1个字节的数据是不能压缩的。
所以我的问题是,为什么CHUNK大小只影响压缩速度,而不影响压缩率?
这是我的程序:
#define CHUNK 16384
int def(FILE *source, FILE *dest, int level, int memLevel)
{
int ret, flush;
unsigned have;
z_stream strm;
unsigned char in[CHUNK];
unsigned char out[CHUNK];
/* allocate deflate state */
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
ret = deflateInit2(&strm, level, Z_DEFLATED, MAX_WBITS + 16, memLevel, Z_DEFAULT_STRATEGY);
if (ret != Z_OK)
return ret;
/* compress until end of file */
do {
strm.avail_in = fread(in, 1, CHUNK, source);
if (ferror(source)) {
(void)deflateEnd(&strm);
return Z_ERRNO;
}
flush = feof(source) ? Z_FINISH : Z_NO_FLUSH;
strm.next_in = in;
/* run deflate() on input until output buffer not full, finish
compression if all of source has been read in */
do {
strm.avail_out = CHUNK;
strm.next_out = out;
ret = deflate(&strm, flush); /* no bad return value */
assert(ret != Z_STREAM_ERROR); /* state not clobbered */
have = CHUNK - strm.avail_out;
if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
(void)deflateEnd(&strm);
return Z_ERRNO;
}
} while (strm.avail_out == 0);
assert(strm.avail_in == 0); /* all input will be used */
/* done when last data in file processed */
} while (flush != Z_FINISH);
assert(ret == Z_STREAM_END); /* stream will be complete */
/* clean up and return */
(void)deflateEnd(&strm);
return Z_OK;
}
因为 deflate 在内部缓冲数据以进行压缩。无论您如何提供数据以放气,它都会累积并压缩字节,直到它有足够的空间来发出放气块。
你说得对,你不能压缩一个字节。如果你想看看这是多么真实,然后将 flush
从 Z_NO_FLUSH
更改为 Z_FULL_FLUSH
然后一次给它一个字节。然后确实 deflate 会尝试分别压缩输入的每个字节。