Comment by lifthrasiir
5 months ago
Virtually every use case of zlib (can be used to implement gzip) should be replaced with zlib-ng, in fact. The stock zlib is too slow for modern computers. If you have a right workload---no streaming, fit in memory etc.---, then libdeflate is even faster. The compression can't be a bottleneck when you've got a correct library.
zlib-rs (the rust port) is now faster in most cases (which exposes a zlib compatible API)
Fun fact: Turning off permessage deflate is nearly impossible when browsers are in the mix, best Option is to strip the header in a reverse proxy, since many browsers ignore the setting and emits the header despite your configs - add to that that most SERVERs assume the client knows what it is doing and adhere to the header request while not allowing a global override to turn it off.
gives you a fun ball of yarn to untangle
Patently untrue,
Seriously try to Deflate a 50mb compressed json structure vs just piping it down the wire on a high bandwith connection and try to measure that. (In real life with a server and browser - browsers are super slow at this)
> browsers are super slow at this
No, DEFLATE is an asymmetric compression algorithm, meaning that decompression is disproportionally faster (at least 100 MB/s in my experience) than compression. It should mostly be a server's fault to use too high and ineffective compression setting or to use an inefficient library like the stock zlib.
> The compression can't be a bottleneck when you've got a correct library.
It absolutely can tho. You’re not going to do memory compression using zlib regardless of its flavour.
In this context, of course. It is not a general statement ;-)
ramdisk!