[lifthrasiir]

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.

[nicoburns]

zlib-rs (the rust port) is now faster in most cases (which exposes a zlib compatible API)

[bythreads]

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

[bythreads]

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)

[lifthrasiir]

> 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.

[masklinn]

> 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.

[lifthrasiir]

In this context, of course. It is not a general statement ;-)

[bythreads]

ramdisk!