java c s测试_将Zlib Java与C进行基准测试
我試圖通過切換到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％的壓縮率。 感謝您為開發該產品所做的辛勤工作！
總結
以上是生活随笔為你收集整理的java c s测试_将Zlib Java与C进行基准测试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java选择循环_java选择和循环结构
- 下一篇： Java主方法引用传递_java方法中的