Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It would also be nice to implement LZMA2 support to content encoding in the browsers, which is much better than GZip.

Firefox started doing it, I think.

https://wiki.mozilla.org/LZMA2_Compression



> which is much better than GZip.

For one value of "better": better compression ratio.

LZMA is also much more expensive than GZip (2x CPU when decompressing, 3x to 6x when decompressing) and uses 2 to 100 times the working memory (when decompressing, the compression is worse). GZip also has more or less constant working memory where LZMA2's depends on compression settings.

LZMA2's use case is thus a bit restricted, mostly pre-compressed static assets (ideally not used on mobile devices)


Compression is done on the server, and (hopefully) once per unique response, which is then cached.

Decompression is fast. I don't think memory is an issue when we're talking about decompressing some HTML/CSS/Javascript, considering it only is required for a few milliseconds to do the work.

CPU is barely an issue, considering how powerful modern mobile devices,

New phones seem to have as much power and as much RAM as my 5 year old PC.


> Compression is done on the server, and (hopefully) once per unique response, which is then cached.

Only works for low-dynamicity response. Or fully static assets.

> Decompression is fast.

I quoted numbers. LZMA decompression takes twice as much CPU time as gzip in the best case.

> I don't think memory is an issue when we're talking about decompressing some HTML/CSS/Javascript

Memory is not a function of payload size in compression algorithms, it's a function of compression parameters. xz -9 will have ~65MB of memory overhead regardless of the payload size (and LZMA is flexible enough that you can craft a single payload requiring gigabytes of working memory, xz's man even warns about it).

> CPU is barely an issue, considering how powerful modern mobile devices

CPU transitions are extremely aggressive on mobiles. The more CPU time has to be spent decompressing payloads the less the CPU can be in deep hibernation state and the more battery you burn through.

Not a tradeoff which makes much sense considering >3G bottlenecks tend to be latency and processing more than bandwidth for "basic" HTML/CSS/JS web content (and really most things outside of video streaming)

> New phones seem to have as much power and as much RAM as my 5 year old PC.

Phones usually can't page out, and aren't tethered to a wall.

Also depends which "new phones" you're looking at, the Firefox OS-based ZTE Open has 256MB RAM and a 1GHz single-core Cortex A5.


Twice as tiny is still very small.

In this case, bandwidth is a more scare resource than CPU/RAM.


For me, the difference in CPU between gzip and lzma is more expensive than the bandwidth difference. I'm much more often processing constrained than bandwidth constrained.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: