Neal Gompa wrote: > Regular zstd compression is less optimized due to the lack of > dictionaries, but it's also effectively the fallback path, though much > faster to decompress while providing pretty good compression (which is > why we have been gradually switching *everything* to zstd). "pretty good" if you only really care about speed. It loses to the much older xz in almost all compression ratio benchmarks, often significantly (e.g., xz compresses text (enwik8 testcase) with a factor 4 (*), zstd only with a factor 2.5 [1]). So I still think zstd is a step backwards compared to xz. (*) The factor 4 is with xz -9, but you should always use that because the decompression is no slower, and in fact actually slightly faster, with it than with lower compression levels, only the compression is slower, but the compression happens once on the server. [1] source: https://quixdb.github.io/squash-benchmark/ Kevin Kofler -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
