Case where brotli quality 9 compresses better than quality 11 #135

New Issue

claunia · 2026-01-29T20:37:40Z

claunia commented

2026-01-29 20:37:40 +00:00

Originally created by @joshtriplett on GitHub (Aug 15, 2016).

I found a test case where brotli with quality 9 compresses better than with quality 11. This seemed worth reporting in case there might be some convenient way to detect and handle this case (short of compressing the whole file both ways to check).

Test case and compressed versions: brotli-test.tar.gz

(This test case came from a locally modified version of bsdiff that doesn't use bzip2 internally, so that I could test it with brotli. The bsdiff goes from jquery-2.2.3.min.js to jquery-2.2.4.min.js .)

Compressing jquery.ubsdiff with brotli quality 11 produces 264 bytes; compressing with quality 9 produces 252 bytes.

Originally created by @joshtriplett on GitHub (Aug 15, 2016). I found a test case where brotli with quality 9 compresses better than with quality 11. This seemed worth reporting in case there might be some convenient way to detect and handle this case (short of compressing the whole file both ways to check). Test case and compressed versions: [brotli-test.tar.gz](https://github.com/google/brotli/files/417342/brotli-test.tar.gz) (This test case came from a locally modified version of [bsdiff](http://www.daemonology.net/bsdiff/) that doesn't use bzip2 internally, so that I could test it with brotli. The bsdiff goes from jquery-2.2.3.min.js to jquery-2.2.4.min.js .) Compressing jquery.ubsdiff with brotli quality 11 produces 264 bytes; compressing with quality 9 produces 252 bytes.

claunia commented

2026-01-29 20:37:42 +00:00

@eustas commented on GitHub (Aug 15, 2016):

Thanks for the report. I'll investigate it later. Feel free to ping me in a month or so, it I do not report back...

@eustas commented on GitHub (Aug 15, 2016): Thanks for the report. I'll investigate it later. Feel free to ping me in a month or so, it I do not report back...

claunia commented

2026-01-29 20:37:44 +00:00

@RajuSuranagi commented on GitHub (Jun 25, 2018):

@eustas, since it has been more than a month and @joshtriplett didn't ping you, is there anything on this question? I am just curious about the number 11 than anything else. Why 11?

@RajuSuranagi commented on GitHub (Jun 25, 2018): @eustas, since it has been more than a month and @joshtriplett didn't ping you, is there anything on this question? I am just curious about the number 11 than anything else. Why 11?

claunia commented

2026-01-29 20:37:45 +00:00

@dikmax commented on GitHub (Jun 29, 2018):

@RajuSuranagi Homage to Spın̈al Tap I suppose.

@dikmax commented on GitHub (Jun 29, 2018): @RajuSuranagi Homage to Spın̈al Tap I suppose.

claunia commented

2026-01-29 20:37:47 +00:00

@mraszyk commented on GitHub (Jul 10, 2018):

I looked a bit into it, and it seems that brotli literal costs estimates are spoiled by the many zeros in the test file. In fact, brotli quality 10 performs ~10% worse than quality 9, whereas 9 and 11 are rather close. When inspecting the compressed files, I noticed that quality 10 produces less commands and more literal insertions than 11. Raising the estimated literal cost if it is smaller than 1.0 in BrotliEstimateBitCostsForLiterals mitigates the issue to some extent, and actually improves compression at quality 11 for the provided test file.

The challenge would be to not break benchmarks on other corpora by playing with the cost estimates.

@mraszyk commented on GitHub (Jul 10, 2018): I looked a bit into it, and it seems that brotli literal costs estimates are spoiled by the many zeros in the test file. In fact, brotli quality 10 performs ~10% worse than quality 9, whereas 9 and 11 are rather close. When inspecting the compressed files, I noticed that quality 10 produces less commands and more literal insertions than 11. Raising the estimated literal cost if it is smaller than 1.0 in BrotliEstimateBitCostsForLiterals mitigates the issue to some extent, and actually improves compression at quality 11 for the provided test file. The challenge would be to not break benchmarks on other corpora by playing with the cost estimates.

claunia commented

2026-01-29 20:37:50 +00:00

@RajuSuranagi commented on GitHub (Jul 11, 2018):

Thanks for the insight!

@RajuSuranagi commented on GitHub (Jul 11, 2018): Thanks for the insight!

claunia referenced this issue

2026-01-29 20:50:41 +00:00

[PR #135] [MERGED] Fix malloc.h and stdlib.h includes. #751

Sign in to join this conversation.