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