Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!usenet.ins.cwru.edu!ncoast!allbery
From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA)
Newsgroups: comp.unix.shell
Subject: Re: read in /bin/sh appears to be VERY cpu costly.
Message-ID: <1991May11.013354.5879@NCoast.ORG>
Date: 11 May 91 01:33:54 GMT
References: <1991May8.013013.29811@brolga.cc.uq.oz.au>
Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA)
Followup-To: comp.unix.shell
Organization: North Coast Public Access Un*x (ncoast)
Lines: 31

As quoted from <1991May8.013013.29811@brolga.cc.uq.oz.au> by ggm@brolga.cc.uq.oz.au (George Michaelson):
+---------------
| simple tests using time on a shellscript of:
| 
| 	while 1
| 	do
| 		read INP
| 		echo $INP
| 	done
| 
| seem to suggest that read is incredibly expensive on the CPU.
+---------------

Do you know that it's "read" that is expensive?  The other possibilities are:
"while/do/done" and "echo".  Not to mention that "while 1" returns "1: not
found" on my system (admittedly, not a Sun 4), and the cost of interpolating
and expanding the "echo" command line.

A better test of the speed of "read" is to time a script containing only
"read" statements.  Also time an empty script so you can factor out the shell
startup time, for still better accuracy.

(Note: if your timing tests did in fact take this into account, you should
probably have said so.)

++Brandon
-- 
Me: Brandon S. Allbery			  Ham: KB8JRR/AA  10m,6m,2m,220,440,1.2
Internet: allbery@NCoast.ORG		       (restricted HF at present)
Delphi: ALLBERY				 AMPR: kb8jrr.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery       KB8JRR @ WA8BXN.OH