In a one word answer: Mobile.

LZ4 might be better at compressing, but it has worse performance characteristics. But don't take my word for it:

http://catchchallenger.first-world.info//wiki/Quick_Benchmar...

As you can see, LZ4 uses 30x as much memory as gzip.

This benchmark is a fairly bad reference.

It measures memory usage from the lz4 command line utility, without mentioning it. This is completely different from lz4 algorithm.

Effectively, it measures input / output buffers, which are external to lz4. Plus it uses highest settings for such buffers, also without mentioning it. Using -B4 setting, for example, would reduce I/O buffer memory by a 50X factor.

lz4 itself uses only 16KB for compression.

Memory usage isn't that big of a concern anymore, not when phones ship with 1 or more GB of memory regularly.

And that doesn't answer my question: I'm okay with gzip also being allowed, but the whole entire reason we allow multiple compressors is so the web browser and the web server can negotiate what features are supported.

Low memory HTTP clients, yes, can continue to use gzip. But the rest of us, why are we not using LZ4? I mean, hell, there is no reason why HTTP 1.0 and 1.1 clients can't also support LZ4 as well: they just have to negotiate for the feature.

> Memory usage isn't that big of a concern anymore, not when phones ship with 1 or more GB of memory regularly.

Memory access costs power and time (which = power too).

Yes it does, but does it cost more than the CPU power used by gzip vs the memory access cost of lz4? I suspect the CPU cost is more by at least a magnitude (although I can't measure it, but I bet Google has frameworks for Android to).

I don't want my browser on my phone to require a gb of memory thank you very much.

It's bad enough that desktop browsers like chrome are complete memory hogs without stuff like this, I hate to imagine what a phone browser would be like if "fuck it, modern phones have heaps of resources" was the approach to all decisions.

Next you'll be suggesting a compression algorithm that only works anywhere near realtime when it has 8x1ghz+ cores to spread the work over.

Your phone won't require it. It will temporarily use slightly more memory (12MB is very little on modern Android phones), and it would decrease the time required to render the page (due to less CPU power required to compress then decompress over gzip -1).

Well, it will use much less than that. The real "memory cost" of decompression will be : + compressed size

and that's it. Decompression doesn't use any memory, only the I/O buffers.

On the compression side, the memory cost is : + buffer for compression (typically == size of data to compress) + 16 KB for tables

And that's it.

We are very very far from the 12 MB mentioned.

My concern is with your general concept of:

> Memory usage isn't that big of a concern anymore

That makes more work for people to do, makes a bigger attack surface for hackers.

Also 12MB of memory used on compression (as seen in Someone1234's link) would be pretty bad for a web server.

Edit: Also, do phones have trouble keeping up with gzip decompression? Isn't it layout that's the limiting factor?

Possibly not bigger attack surface. lz4 is already used in a lot of mission/security critical areas, and they have audited many lz4 implementations for security and have found and fixed bugs.

For example, the Linux kernel can use LZ4, corporate VPN solutions like OpenVPN can use LZ4, and many other things can use or require LZ4.