Fix CompressionLevel.Optimal for Brotli (#72266)
authorStephen Toub <stoub@microsoft.com>
Fri, 15 Jul 2022 19:14:32 +0000 (15:14 -0400)
committerGitHub <noreply@github.com>
Fri, 15 Jul 2022 19:14:32 +0000 (15:14 -0400)
commitf281393412758b1345a8dc5073b91f9e950e683d
treef58ad559244dfcb6267cda0148b681c6d5461f30
parentaa3eddbc3ed83f5dba65b1229e3f5d67aeff4a6c
Fix CompressionLevel.Optimal for Brotli (#72266)

The intent of Optimal is to be a balanced trade-off between compression ratio and speed, but whereas DeflateStream, GZipStream, and ZLibStream all treat Optimal as such (using zlib's default setting for such a balanced tradeoff), Brotli treats Optimal the same as maximum compression, which is very slow.  Especially now that maximum compression is expressible as CompressionLevel.SmallestSize, it's even more valuable for Optimal to represent that balanced tradeoff.  Based on a variety of sources around the net and some local testing, I've changed the Optimal value from 11 to 4.  This is also more important now that we've fixed the argument validation bug that allowed arbitrary numerical values to be passed through unvalidated (DeflateStream, GZipStream, and ZLibStream all properly validate).
src/libraries/System.IO.Compression.Brotli/src/System/IO/Compression/BrotliStream.cs
src/libraries/System.IO.Compression.Brotli/src/System/IO/Compression/BrotliUtils.cs
src/libraries/System.IO.Compression.Brotli/src/System/IO/Compression/enc/BrotliStream.Compress.cs