read in /bin/sh appears to be VERY cpu costly.

heinz at cc.univie.ac.at heinz at cc.univie.ac.at
Thu May 16 00:08:13 AEST 1991


allbery at NCoast.ORG (Brandon S. Allbery KB8JRR/AA) writes:

>As quoted from <1991May8.013013.29811 at brolga.cc.uq.oz.au> by ggm at 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.

Well, "read" shouldn't consume too much CPU time, since it is essentially a
blocking I/O operation and doesn't account to CPU consumption. What really *is*
costly is the while/do/done. I've tried a while-loop in the GNU-bash on a SUN-3,
where the loop body was a single "echo", and it put an awful load on the
machine (actually, by running this loop simultaneously in several windows, you
can prevent other people -and yourself- from doing anything useful :)
Even a completely empty while-loop was sufficient to pose a significant delay
on other jobs.
So it is the shell itself that consumes the CPU time.

--
Heinz Herbeck (heinz at sophie.pri.univie.ac.at)



More information about the Comp.unix.shell mailing list