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 [pickfire_AT_riseup.net]
Sent: 14 June 2017 09:18
To: dev_AT_suckless.org
Subject: Re: [dev] [sbase] Changing BUFSIZ
Mattias Andrée <maandree_AT_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/
Received on Wed Jun 14 2017 - 14:36:35 CEST