我试图通过切换到C来加快最初用Java编写的TIFF编码器的速度，并已编译了Zlib 1.2.8，其中定义了Z_SOLO并包含最少的C文件集：adler32.c，crc32.c，deflate.c，< x4>和zutil.c。 Java正在使用java.util.zip.Deflater。

我编写了一个简单的测试程序来评估压缩级别和速度方面的性能，但我感到困惑的是，无论我需要什么级别，考虑到更高级别所需的时间越来越长，压缩都不会发挥太大作用。 Java在压缩和速度方面的性能都比Visual Studio Release-compile(VC2010)更好，我也对此感到惊讶：

Java：

Level 1 : 8424865 => 6215200 (73,8%) in 247 cycles.

Level 2 : 8424865 => 6178098 (73,3%) in 254 cycles.

Level 3 : 8424865 => 6181716 (73,4%) in 269 cycles.

Level 4 : 8424865 => 6337236 (75,2%) in 334 cycles.

Level 5 : 8424865 => 6331902 (75,2%) in 376 cycles.

Level 6 : 8424865 => 6333914 (75,2%) in 395 cycles.

Level 7 : 8424865 => 6333350 (75,2%) in 400 cycles.

Level 8 : 8424865 => 6331986 (75,2%) in 437 cycles.

Level 9 : 8424865 => 6331598 (75,2%) in 533 cycles.

C：

Level 1 : 8424865 => 6215586 (73.8%) in 298 cycles.

Level 2 : 8424865 => 6195280 (73.5%) in 309 cycles.

Level 3 : 8424865 => 6182748 (73.4%) in 331 cycles.

Level 4 : 8424865 => 6337942 (75.2%) in 406 cycles.

Level 5 : 8424865 => 6339203 (75.2%) in 457 cycles.

Level 6 : 8424865 => 6337100 (75.2%) in 481 cycles.

Level 7 : 8424865 => 6336396 (75.2%) in 492 cycles.

Level 8 : 8424865 => 6334293 (75.2%) in 547 cycles.

Level 9 : 8424865 => 6333084 (75.2%) in 688 cycles.

我是唯一看到这种结果的人吗？我的猜测是JVM中的Zlib正在使用我不包含在我的C项目中的程序集类型优化，或者在编译Zlib(或Visual Studio编译器很烂)时缺少一个明显的配置步骤。

这两个片段：

Java：

public static void main(String[] args) throws IOException {

byte[] pix = Files.readAllBytes(Paths.get("MY_MOSTLY_UNCOMPRESSED.TIFF"));

int szin = pix.length;

byte[] buf = new byte[szin*101/100];

int szout;

long t0, t1;

for (int i = 1; i <= 9; i++) {

t0 = System.currentTimeMillis();

Deflater deflater = new Deflater(i);

deflater.setInput(pix);

szout = deflater.deflate(buf);

deflater.finish();

t1 = System.currentTimeMillis();

System.out.println(String.format("Level %d : %d => %d (%.1f%%) in %d cycles.", i, szin, szout, 100.0f*szout/szin, t1 - t0));

}

}

C：

#include

#define SZIN 9000000

#define SZOUT 10000000

void main(void)

{

static unsigned char buf[SZIN];

static unsigned char out[SZOUT];

clock_t t0, t1;

int i, ret;

uLongf sz, szin;

FILE* f = fopen("MY_MOSTLY_UNCOMPRESSED.TIFF","rb");

szin = fread(buf, 1, SZIN, f);

fclose(f);

for (i = 1; i <= 9; i++) {

sz = SZOUT;

t0 = clock();

compress2(out, &sz, buf, szin, i); // I rewrote compress2, as it's not available when Z_SOLO is defined

t1 = clock();

printf("Level %d : %d => %d (%.1f%%) in %ld cycles.\

", i, szin, sz, 100.0f*sz/szin, t1 - t0);

}

}

编辑：

@MarkAdler发表评论后，我尝试通过deflateInit2()(即Z_FILTERED和Z_HUFFMAN_ONLY)使用不同的压缩策略：

Z_FILTERED：

Level 1 : 8424865 => 6215586 (73.8%) in 299 cycles.

Level 2 : 8424865 => 6195280 (73.5%) in 310 cycles.

Level 3 : 8424865 => 6182748 (73.4%) in 330 cycles.

Level 4 : 8424865 => 6623409 (78.6%) in 471 cycles.

Level 5 : 8424865 => 6604616 (78.4%) in 501 cycles.

Level 6 : 8424865 => 6595698 (78.3%) in 528 cycles.

Level 7 : 8424865 => 6594845 (78.3%) in 536 cycles.

Level 8 : 8424865 => 6592863 (78.3%) in 595 cycles.

Level 9 : 8424865 => 6591118 (78.2%) in 741 cycles.

Z_HUFFMAN_ONLY：

Level 1 : 8424865 => 6803043 (80.7%) in 111 cycles.

Level 2 : 8424865 => 6803043 (80.7%) in 108 cycles.

Level 3 : 8424865 => 6803043 (80.7%) in 106 cycles.

Level 4 : 8424865 => 6803043 (80.7%) in 106 cycles.

Level 5 : 8424865 => 6803043 (80.7%) in 107 cycles.

Level 6 : 8424865 => 6803043 (80.7%) in 106 cycles.

Level 7 : 8424865 => 6803043 (80.7%) in 107 cycles.

Level 8 : 8424865 => 6803043 (80.7%) in 108 cycles.

Level 9 : 8424865 => 6803043 (80.7%) in 107 cycles.

正如他的评论所期望的那样，Z_HUFFMAN_ONLY不会更改压缩，但是执行速度要快得多。根据我的数据，Z_FILTERED的压缩速度并没有比Z_DEFAULT_STRATEGY快一些。

我很惊讶级别3最小。您确定数据没有什么奇怪的地方吗？

@PeterLawrey是一个"标准" TIFF文件，大小为2800x2900，包含2页，第一页未压缩，第二页进行deflate压缩。我可以理解为"压缩压缩数据使它们膨胀"。我可以尝试压缩已经压缩的数据，以查看发生了什么(如果我在本周末有时间)。

在Java程序中，请注意fis.read(pix)可能无法读取整个文件，在这种情况下，pix的其余部分将为零。我建议用pix = Files.readAllBytes(Paths.get("MY_MOSTLY_UNCOMPRESSED.TIFF"))代替FileInputStream的使用。

您获得的压缩量取决于数据。大多数图像文件已经被很大程度地压缩，因此您不太可能会看到太多额外的压缩。

@VGR感谢您的提示。在我的quickndirty测试中，我确保缓冲区足够大，并且似乎读取了所有字节(与C中的数字相同)。

确实是@HotLicks。但是我期望随着level的增加，压缩会越来越好，而不是立即看到" max-I-can-get"，而没有得到很大的改善(正如@PeterLawrey注意到的那样，它令人惊讶地从0下降到3，然后上升从4点开始，然后下降一点)。

不奇怪。每个"级别"是不同的算法，并且某些"级别"在给定数据上的效果更好(或者在这种情况下，开销可能更小)。

@Matthieu您是否尝试过使unsigned chars无符号ints？每次将其装入时，都必须将其转换为int。这样可以加快速度。

@progenhard Zlib期望使用unsigned char*指针(在Zlib中为Bytef*)，考虑到图像的大小(和数量)，内存增加4倍并不值得Zlib骇客。

对于基本上没有匹配字符串的未压缩图像数据，压缩量和增量并不奇怪。 压缩的数据部分不会进一步压缩-只是以一定的数量进行扩展，因此变化全部在未压缩的部分上。

3级和4级之间的算法有所不同，其中3级用于它找到的第一个匹配项。 当几乎没有匹配的字符串时，这将使发送字符串匹配的开销最小化，因此压缩效果更好。 如果使用FILTERED或HUFFMAN_ONLY完全关闭了字符串匹配，则可能会做得更好。 HUFFMAN_ONLY还具有甚至不寻找匹配字符串的优点，从而大大加快了压缩速度。

至于速度差异，我只能猜测使用了不同的编译器或不同的编译器优化。

HUFMAN_ONLY也可以在Java中设置吗？

实际上，HUFFMAN_ONLY是setStrategy的Java选项。 在zlib中，它称为Z_HUFFMAN。

谢谢，这解释了原因。 如果有时间，请尝试使用FILTERED和HUFFMAN_ONLY并发布结果。

我用Z_FILTERED和Z_HUFFMAN_ONLY获得的结果更新了帖子。 我喜欢Z_HUFFMAN_ONLY策略仍然可以由JAI(TIFF读取器Im使用)解码，尽管它在测试斜坡图像(0、1、2、3，...，254、255)上完全没有压缩 ，0，...)，在实际示例中仍可提供80％的压缩率。 感谢您为开发该产品所做的辛勤工作！