Date: Tue, 10 Feb 2015 02:24:51 +0000 From: Glen Barber <gjb@FreeBSD.org> To: Dmitry Morozovsky <marck@rinet.ru> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Rui Paulo <rpaulo@freebsd.org> Subject: Re: svn commit: r278433 - in head: . contrib/xz contrib/xz/src/common contrib/xz/src/liblzma contrib/xz/src/liblzma/api contrib/xz/src/liblzma/api/lzma contrib/xz/src/liblzma/check contrib/xz/src/liblz... Message-ID: <20150210022451.GA14325@hub.FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1502091606070.94441@woozle.rinet.ru> References: <201502090620.t196KZSk040702@svn.freebsd.org> <20150209122540.GE84467@hub.FreeBSD.org> <20150209123057.GF84467@hub.FreeBSD.org> <alpine.BSF.2.00.1502091606070.94441@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 09, 2015 at 04:08:00PM +0300, Dmitry Morozovsky wrote: > > > FWIW, compressing VM images (some sparse files, some not) would take > > > upwards of 45 minutes, which after this update, just takes a few > > > minutes. > > >=20 > > > root@releng2:/R2/vmimages # time xz -T 0 -k FreeBSD-11.0-CURRENT-amd= 64.qcow2 \ > > > time xz -T 0 -k FreeBSD-11.0-CURRENT-amd64.raw; \ > > > time xz -T 0 -k FreeBSD-11.0-CURRENT-amd64.vhd; \ > > > time xz -T 0 -k FreeBSD-11.0-CURRENT-amd64.vmdk > > > 1027.602u 40.376s 1:09.57 1535.1% 81+192k 0+19774io 0pf+0w > > > 1032.978u 38.823s 1:08.17 1572.2% 81+192k 0+19696io 0pf+0w > > > 1033.908u 38.593s 1:11.70 1495.8% 81+192k 0+19729io 0pf+0w > > > 1091.749u 42.371s 1:04.27 1764.6% 81+192k 0+19751io 0pf+0w > > >=20 > >=20 > > I meant to include that this is on a 48-core machine. >=20 > Hm, I can't beleive you didn't use pxz ;) >=20 For RE purposes, using base system utilities supersedes utilities available elsewhere. In my initial tests with pxz, there was an, albeit somewhat predictable, increase in resulting file size as the number of threads increased, while xz in base with the latest update produces output files within +/-1024Kb difference of the unthreaded version. For RE side, there was no real gain in using pxz over xz, because the sacrifice was the output file size. I do not care so much about the time taken to compress the files. I *do* care about the resulting file size, since I (personally) want to be sure that the end user can download the smallest possible file. I was unsure what to expect with the xz(1) update in this regard, and was surprised to see a non-visible difference in the resulting file. > Anyway, having this in base, and not depending on external tool, is=20 > amazingly great. >=20 > BTW, Rui, did you some comparative tests with pxz? >=20 As stated above, pxz (last I tested) produces incrementally larger files as the thread count increases. From what I have seen so far, the latest xz update does not. Glen --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU2WvzAAoJEAMUWKVHj+KTcZAP/05b3Ek+OnlbxvpkouzPDLMS LF88/Ru8vcV6vMc4IN/Z8Mgnmb97MC4TYu9oDrn7mj+PY47xKGSsecVNftE4zMuz 4snCCc6htHzD+PSWY4YwPw6BxycuyIp6vchcwNKH0Quhxgzum+K75XxmBmwKfl+7 aPUuFIGfvV2L2PJG0XDf46ZXXDdMyB5Y/XH0khARhbmV2jb/uFhsohc8qsn9ZLY0 R1TanKIrLTGgNiFaS9/uCLkyMHb3f3TBNw6SvNqQ/3OiHfp0GFqNBycPIGdKNTxV extCaKcweIgwpyEZK/7fkttLU5PKKQzPF/QR75azRd5KiUVxGAeg1ZDKbnlEh/3x WLTV4uPCaB8oLcx5bMXIM5EASgvgHG/H7WySEaFbV51EPYvmW1FsjOF//YHMDrIU sxlEvuIzjxnXMREkiByzYschE/f44gsKiPpTkXm/TWRzzooqOkNMBcMuKqHR0d3x WSUoEyN/fD4vFN/VRhTboqIkHoA6C5qzaAu99huVm/BR6fx/TxZJIvLTzI8j3iD+ nub31GyBOwHXiNKe50pp621gKpJhyUowoTpT3aPBIZVzgRfHuQFHCc4ahYZ0yYRT 16/pi8tAIGjrABkwxfPQ4ZiqL1JxJLlD48j9VN1X4NVInsmU+QprQoXDZAO4DHb4 lwPRKg/FzMRXJ8bW8s5i =C+sN -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150210022451.GA14325>