[Annatar]

I couldn't care less about decompression speed, because the bottleneck is the network, which means that I want my packages as small as possible. Smaller packages mean faster installation; at 54 MB/s or faster decompression rate of xz, I couldn't care less about a few milliseconds saved during decompression. For me, this decision is dumbass stupid.

[nullc]

Per the post, the speedup on decompress is _13x_ while the size is 1.008x.

For those figures, this will be better total time for you if your computer network connection is faster than about 1.25mbit/sec. For a slow arm computer with an XZ decompress speed of 3MB/s the bandwidth threshold for a speedup drops to _dialup_ speeds.

And no matter how slow your network connection is and how fast your computer is you'll never take more than 0.8% longer with this change.

For many realistic setups it will be faster, in some cases quite a bit. Your 54MB XZ host should be about 3% faster if you're on a 6mbit/sec link-- assuming your disk can keep up. A slow host that decompresses xz at 3MB/s w/ a 6mbit link would a wopping 40% faster.

[ubercow13]

Why do you care so much about the few extra miliseconds wasted downloading, then? (0.8% size increase is ~ 0). Also don't forget that Arch can also be used on machines with very slow CPU but very fast network connections, like many VPSs. I think this will make a tangible difference on mine. This is also a big improvement for package maintainers and anyone building their own packages without bothering to modify the makepkg defaults, eg. most people using an AUR helper.

[Annatar]

Because size does matter.

[powturbo]

There are nice plots [1] to see the tranfer+decompression speedup depening on the network bandwidth.

This is for html web compression, but the results are similar for other datasets. For internet transfer more compression is better than more decompression speed.

You can make your own experiments incl. the plots with turbobench [2]

[1] https://sites.google.com/site/powturbo/home/web-compression [2] https://github.com/powturbo/TurboBench

[snvzz]

The extra decompression complexity might be a joke on a Zen2 server, but it definitely is not in older systems.

If this was netbsd m68k, you'd probably easily understand.

[Annatar]

I use xz on my A1200 all of the time, and Amiga is the stereotypical system where maximum possible compression matters over everything else. Don't make assumptions about me.

[snvzz]

I applaud your patience. Even with my vampire, I'll use something faster whether at all possible.

May I ask, why xz over, say, PAQ8PF?

[Annatar]

Because my Amiga: volume is actually an NFS share on my Solaris 10 central storage server in the basement. With xz(1) I'm easily portable across systems.

And you're talking to a guy who had his C128D spend all nights crunching intros + pic + game at 1 MHz in Cruel Cruncher 2.5+ and Time Cruncher 5.0 before that. xz(1) on a MC68030 or the Vampire is super fast in comparison.

[snvzz]

So Zstd won't run/build on Solaris or AmigaOS?

Solaris 10 as in the last one from Sun (Damn Oracle...) is an interesting choice. Does openindiana not run well on the old hardware?

[Annatar]

I don't know whether it'll build because I'm interested in maximum compression -- time spent compressing is immaterial to me since it's only done once. It's like compiling -- I don't care how long it takes if it generates fast machine code, because it's running the generated machine code that will matter many, many times afterwards.

Is Core2 Quad with 8GB of RAM or a Sun X4100 M2 "older hardware"?