Hacker News Reader

Comment by bibyte | Hacker News Reader

From my experience GNU CLI tools make a particular effort to be really fast (even on embedded hardware).

I think this is originally to avoid any possible plagiarism claims by Unix--if a Unix tool was originally optimized for one of size/efficiency/speed/memory use, the GNU tools were optimized for one of the others. This is part of why the `yes` utility is so freakin fast in GNU, despite being kind of a weird use case for speed.

Mac builtin:

yes | pv > /dev/null

139MiB 0:00:05 [28.4MiB/s]

GNU:

gyes | pv > /dev/null

3.31GiB 0:00:06 [ 584MiB/s]

I don't know if it is or isn't the plagiarism thing but GNU tools were written with a very different, way more modern style than Unix tools.

Unix was pretty much "do a quick loop using terse code" and "see what fits in this static small buffer, and if it doesn't, quietly truncate". GNU would reallocate buffers to fit, and take reasonable precautions on performing well on tiny/huge inputs.

GNU was actually considered bloated by the Unix crowd ("why so many more kilobytes of code?" ). It's an approach that scaled better for the future though.

See section 2.1 of [0] and the top response to this comment [1]. You'll note in the GNU standards there, it encourages optimizing for the opposite of Unix to avoid collisions in strategy.

[0] https://www.gnu.org/prep/standards/standards.html#Reading-No...

[1] https://news.ycombinator.com/item?id=14543536

It obviously has a bit of work put into it to make it fast: https://github.com/coreutils/coreutils/commit/35217221c211f3...

Reply on news.ycombinator.com