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.
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 access costs power and time (which = power too).
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.
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.
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.