While I also like 7z a lot and use it all the time, it's really not a better format that RAR. Higher compression ratios? Sure, marginally. But for archival RAR is still the better choice as it supports recovery records, which 7z still does not. I also found it more difficult to restore data from a partial 7z file (i.e. trailer data is missing) compared to an incomplete RAR file.

> Windows users should use 7-Zip

Please no - no native zstd support. NanaZip is the better option (it's a different build of 7-zip) and it's available at windows store.

> Better compression format, unpacks more kinds of archives

winrar has supported zstd for 5 years[0]

In short - Everyone should be using zstd, and 7-zip does not support it.

[0]: https://www.win-rar.com/singlenewsview.html?&L=0&tx_ttnews%5...

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.

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%*|

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?

dont know the point of the table, but here it is:

  |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%*|

seconding others' request to try with zstd! I'd be very curious what something like zstd -14 would give you

Good point. Looks like it’s related to window size (incl for lzma btw). Lzma stays 0.9 and goes to 88.5 post 8.8M gap. Zstd -14 is close to lzma up to 4.4M where it jumps to 91.5. 14L seems to be the best overall for this scenario staying at 1.9.

zstd is a good default for e.g. filesystem compression, but if you're making an archive file, presumably you're looking for higher compression and LZMA would be a better fit.

> Everyone should be using zstd

Why?

It's just the best general purpose compression algorithm, in terms of compression ratio to CPU used, for the vast majority of use cases

I'm not that fussed about CPU use.

https://github.com/mcmilk/7-Zip-zstd

By these charts, if I only need 5-10 megabytes per second of compression on a single core, LZMA2 wins significantly on ratio, and still decompresses at well over 100. If I'm doing a backup, or sending/receiving over my internet connection (which only has 2MB/s of upload), LZMA2 easily wins. If I need speed then zstd wins.

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

>> Windows users should use 7-Zip

7z is now built into W11 right click so that or zip is what will be used by default anyway.

Last I checked windows handles compressed files in 4 byte or 4kb or something chunks and is incredibly slow to compress or decompress a lot of files.

but worse filebrowser