3 ms·
The problem is brotli compression is pretty expensive/slow to encrypt. Which isn't really a problem for static content that can be compressed ahead of time. But
by thayne 4y ago
The problem is brotli compression is pretty expensive/slow to encrypt. Which isn't really a problem for static content that can be compressed ahead of time. But doesn't work very well for just in time compression.
- dchest 4y agoThis isn't true. Brotli compression speed is similar to Zstd at comparable compression ratios. https://quixdb.github.io/squash-benchmark/unstable/?dataset=enwik8&machine=s-desktop&speed-scale=logarithmic&visible-plugins=zstd,brotli,lz4,lzma,zlib https://quixdb.github.io/squash-benchmark/unstable/?dataset=... Perhaps, this common misunderstanding is due to the fact the slowest level (-11) is the default one in the brotli command line utility? It's also faster than gzip, and gzip was used for "just in time" compression on the web for ages, so I don't see how brotli can be a problem for this use case. (I assume by "encrypt" you mean "compress".)
- thayne 4y agoOn a project I worked on, we tried switching from gzip to brotli for on the fly compression, and it significantly increased CPU usage. That was years ago though so it's possible things are better now, or maybe the library we used just didn't support a compression ratio as low as what we were using with gzip.
- dchest 4y agoFair enough, I think there were some issues with early releases, but they should be fixed now.