I've also seen that. Seems completely silly to care about how quick you can print 'y\n', or whatever string you choose, ad infinitum. There is not real world sitatuion when this is important. Optimising cat(1) however useful for when you want to cat(1) a large file. For example you may want to read the first a file, write something else, and then cat the rest of the file. I do this all the time with blind, except I read output from another process and write it to another. Of course, both other process will do processing so eventually cat(1) will be blocked, but optimising cat(1) in this case may[0] be useful for reducing CPU usage when rendering video.
I don't really understand why GNU put so much working into optimising every last little detail. The only program where this have proven to be useful (for me) is grep(1). They have so many more things they could be spending their resources on. [0] I haven't investigated it yet. Perhaps read(3)/write(3) is not suffient enought and might be required splice(3). P.S. My suggestion puts GNU cat(1) to shame. ________________________________________ From: Ivan Tham [pickf...@riseup.net] Sent: 14 June 2017 09:18 To: dev@suckless.org Subject: Re: [dev] [sbase] Changing BUFSIZ Mattias Andrée <maand...@kth.se> wrote: > On Linux, the performance of cat(1) can be doubled > when cat(1):ing from one pipe to another, by compiling > with -DBUFSIZ=(1<<16) (the default pipe capacity). > This is close to optimial for a read(3)/write(3) > implementation. I have seen people mentioning how is GNU yes fast: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/