4 ms·
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 y
by lifthrasiir 2y 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.
- nicoburns 2y agozlib-rs (the rust port) is now faster in most cases (which exposes a zlib compatible API)
- deleted 2y ago[deleted]
- masklinn 2y ago> 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 2y agoIn this context, of course. It is not a general statement ;-)
- bythreads 2y agoramdisk!
- bythreads 2y agoPatently 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 2y ago> 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.
- bythreads 2y agoFun 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