Daniel Alley wrote: >>ry xz -9, it should be better than zstd. It will take longer to compress, >>but should actually be FASTER (!) to decompress, which is what really >>matters. > > Please provide data - any data - to support this claim, because it flies > completely in the face of every benchmark the internet has to offer, > including the one Sirius performed below. I think you misunderstood what I wrote (which admittedly was somewhat misleading). I mean xz decompresses faster when the input was compressed with xz -9 than when it was compressed with just xz (which according to the manpage currently defaults to xz -6, but in any case, less than -9), which was the context. If you look at https://quixdb.github.io/squash-benchmark/ , wherever a higher compression level actually compresses better (e.g., on the enwik8 or mozilla benchmarks), xz gets slower to compress, but faster to decompress with increasing compression level. (Though if the maximum compression ratio is reached before -9, as on ooffice, decompression will actually get slower again with higher levels. The speedup comes from having less input to process.) xz at any level will of course still be nowhere near zstd in decompression speed. That is not what I intended to claim (and I thought it is obvious that that is not the correct interpretation), though my message was somewhat ambiguous, and I apologize for that. 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
