3 ms·
GNU coreutils 8.24 released
- pixelbeat 11y agoOne thing not mentioned in the link are some performance improvement details. For example the yes command (generally useful for generating repetitive text): $ yes-old | pv > /dev/null ^C ... 55.8MiB/s ... $ yes-new | pv > /dev/null ^C ... 3.44GiB/s ... Details on that fairly simple change are at http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=35217221 http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h... It's interesting there are so many potential improvements in such widely used tools. For example we also more than doubled the speed of wc -l (by avoiding function call overhead): $ yes | pv | wc-old -l ^C ... 230MiB/s ... $ yes | pv | wc-new -l ^C ... 558MiB/s ... For completeness, we now generate an infinite stream of integers more efficiently too: $ seq-old inf | pv > /dev/null ^C ... 13.3MiB/s ... $ seq-new inf | pv > /dev/null ^C ... 497MiB/s ... p.s. I would have used the new `dd status=progress` feature rather than pv above, though pv gives more accurate values due to its use of splice(2). Something to consider for a future version of coreutils
- jakeogh 11y ago"cp,install,mv will convert smaller runs of NULs in the input to holes" Does this imply that --sparce=always is default now?
- pixelbeat 11y agoNo, just that sparsification will work better. 1. cp will detect holes < 128KiB 2. cp --sparse=always it will avoid speculative preallocation used on file systems like XFS, which can have a significant impact on sparsification.