What is on Your Mind?

I do not have an opinion, except that the scrutinizer's test is somewhat flawed, IMO:

#1. The speed difference is because of disk controller caching. Try reversing the order the commands are executed.

Or making two identical copies of the file for the test.

#2. ksh93 mmaps files in that syntactic context, and usually means a single full-on 66 MB I/O request which modern controllers can perform on one request. 66MB may well fit in disk controller cache. So that is a valid result - faster.

Also you need to remove the character special I/O:
my take using one of our compellant SAN:

Code:

# uzpplpl_ng02cprd.log.73 is 160MB 

appworx> time cat uzpplpl_ng02cprd.log.73 > /dev/null

real    0m0.02s
user    0m0.00s
sys     0m0.01s

That measures the overhead required do to a single cat. Zilch, IMO. You have to come up with a way to show me that creating one extra child is important to something like this as well.

OTH creating thousands of children for a cat call inside a loop is a very serious issue, which I think is the origin of the entire UUOC thing.

I did execute all tests various times in different order, on two different platforms it produced no significant difference (per platform). There was a dramatic difference with the repeated plain cat to /dev/null test due to caching which I had also performed of course in prior to these tests (to check its effect), but this thread was not about that. It was about two different methods of feeding into a while read loop, which is what I tested and these results are reproducible.