[enhancement] supply download tarballs as tar.xz instead of .bz2

[anonymous]

you already have .gz tarballs, which is perfect for systems that don't yet support .xz (which at this time are little, any linux system i know supports it and probably even current macOS X releases)

so the only reason for supplying bzip2 downloads must be for smaller storage/download time requirements.

however, xz packs a lot better than bzip2, and bzip2 is a very slow (highly CPU-bound) to unpack algorithm.

on average, extracting .xz is about 3.5 times faster than bzip2.

/dev/shm $ time tar xf boost_1_52_0.tar.bz2

real 0m10.939s user 0m10.747s sys 0m1.390s /dev/shm $ tar cJf boost_1_52_0.tar.xz boost_1_52_0 boost_1_52_0/ boost_1_52_0.tar.bz2 /dev/shm $ time tar cJf boost_1_52_0.tar.xz boost_1_52_0

real 2m12.790s user 2m10.255s sys 0m3.822s /dev/shm $ rm -rf boost_1_52_0 /dev/shm $ time tar xf boost_1_52_0.tar.xz

real 0m4.940s user 0m4.762s sys 0m1.232s /dev/shm $ la boost_1_52_0.tar.xz -rw-r--r-- 1 user users 47673912 Jan 4 10:17 boost_1_52_0.tar.xz /dev/shm $ la boost_1_52_0.tar.bz2 -rw-r--r-- 1 user users 54421709 Jan 4 10:14 boost_1_52_0.tar.bz2

this testing was done on a high-end 3.1 GHZ machine, and here the difference is that xz is more than 2 times faster, and the tarball 7 MB smaller. when using 2 distinct steps to create the .xz archive and invoking the xz compressor with -E (extreme), makes the tarball even smaller.

i also build software regularly on mips and arm platforms in qemu. as an example, untarring the linux kernel sources provides as .bzip2 takes roughly 2 hours, but untarring the .xz archive "only" 30 minutes.

so imo it makes much sense to deprecate .bz2 downloads and replace them with .xz. the .gz files need to stay in order to have a fallback for outdated platforms.

[anonymous]

Lzip is a much better option. See ​http://www.nongnu.org/lzip/lzip_benchmark.html and ​http://www.nongnu.org/lzip/xz_inadequate.html for example.