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. > > > > > > root@releng2:/R2/vmimages # time xz -T 0 -k > > > FreeBSD-11.0-CURRENT-amd64.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 > > > > > > > I meant to include that this is on a 48-core machine. > > Hm, I can't beleive you didn't use pxz ;) >
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 > amazingly great. > > BTW, Rui, did you some comparative tests with pxz? > 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
pgpU5mCMm0vCx.pgp
Description: PGP signature
