|
| ▲ | tnelsond4 3 hours ago | parent | next [-] |
| Yeah, zstd is awesome. I built a webapp that uses it via wasm and the decompression speed is incredible, so much so that I store everything in zstd and decompress it on the app load. My wasm binary also does advanced search and tag insertion and stuff in addition to zstd but it's only 38kb. I wish zstd was supported natively by web browsers. The 8kb implementation of zstd is only half as slow as wasm, so even that is still viable. |
| |
| ▲ | cgio 2 hours ago | parent [-] | | Lzma. I did a simple test, same payload repeated with a gap. Lzma ruled it. |gap |gzip |bz2 |lzma |
|---------|----------|-----|--------|
|0 |2.7% |18.9%|*0.9%*|
|8 KB |2.4% |17.8%|0.9% |
|*40 KB*|*94.4%* |17.7%|0.4% |
|1 MB |*104.3%*|19.7%|*0.9%*| | | |
| ▲ | notpushkin 17 minutes ago | parent [-] | | HN doesn’t support Markdown tables. You can prepend two spaces to show it in monospace though. I don’t see zstd in your comparison? |
|
|
|
| ▲ | aleph_minus_one 3 hours ago | parent | prev [-] |
| > Everyone should be using zstd Why? |
| |
| ▲ | shawabawa3 3 hours ago | parent | next [-] | | It's just the best general purpose compression algorithm, in terms of compression ratio to CPU used, for the vast majority of use cases | | | |
| ▲ | xxs 3 hours ago | parent | prev [-] | | It's just this good. On a more realistic note: few years back, I've added zstd compression to our log subsystem (hand written direct buffers, native code, in-process, java). For the same CPU utilization if provides twice dense compression compared to regular [-6] gzip (the topic in the title). Zstd is =much= faster on decompression as well, and it this case - unparalleledly better as it uses twice less disk. zstd is 'silicon valley' (the tv show) - life imitates fiction, except entirely open source |
|
