3 ms·
The throughput of GNU yes may be higher, but the simpler unbuffered implementations probably have a shorter latency to first line output, and since in most cas
by fmajid 4y ago
The throughput of GNU yes may be higher, but the simpler unbuffered implementations probably have a shorter latency to first line output, and since in most cases the program on the other end of the pipe only reads a handful of line, or more liely just one, this means they will actually be faster.
- bonzini 4y agoUsing puts, fputs or fwrite (which is what the other implementations do) also buffers, so all the GNU implementation does is special case the buffer to remove the overhead of stdio.
- rbanffy 4y agoIs the performance gain worth the less legible implementation?
- jcelerier 4y agoI have never read the source of yes but used it so for me it could be 20 megabytes of source for what I know - as long as it is efficient why would I care ?
- rbanffy 4y agoHow does that efficiency reflect in actual usage? I’d imagine the time waiting for a “y” would be negligible for all but the most trivial tasks.
- jcelerier 4y agogrepping for yes being piped in shell scripts yields a couple hundred matches in my computer - small things add up
- rbanffy 4y agoHow much time is spent generating a “y” compared to do the job the yes is being piped in? In a million years it’d have spared… about a 386 worth of compute ;-)
- MichaelBurge 4y agoI use "yes > file" to benchmark IO, knowing that this is pretty much the "speed of light" for writes. I could use "cp /dev/urandom file" but then it's hard to tell if the filesystem or kernel optimize a copy different from generating your own writes.
- deleted 4y ago[deleted]
- kevincox 4y agoOn the other hand the program you are piping it to likely needs to do some setup as well. Plus with the fact that shells probably spawn the pipeline in order and that the setting up the buffer is incredibly cheap it would be incredibly rare that the first write wasn't done before the program did the first read. ...of course this can be more complicated if you are CPU starved and these programs are competing. Probably the more useful metric is total efficiency. How many interactions need to occur before the setup cost is made back up. And how many lines are read on average from yes?
- masklinn 4y ago> but the simpler unbuffered implementations probably have a shorter latency to first line output I tested this by taking the freebsd (buffered) implementation, stripping all the iterations, and comparing it against a version which also strips all the buffering (so the latter would just `write(STDOUT_FILENO, "y\n", 2)`, and the former would first fill an 8k buffer then write that). The unbuffered implementation has an edge of about 1%, for a variance of above 10%. The "shorter latency" is essentially nonexistent.