Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!email!swdsrv.edvz.univie.ac.at!heinz From: heinz@cc.univie.ac.at Newsgroups: comp.unix.shell Subject: Re: read in /bin/sh appears to be VERY cpu costly. Message-ID: Date: 15 May 91 14:08:13 GMT References: <1991May8.013013.29811@brolga.cc.uq.oz.au> <1991May11.013354.5879@NCoast.ORG> Sender: news@swdsrv.edvz.univie.ac.at Organization: Vienna University Computer Center Lines: 32 Nntp-Posting-Host: sophie.pri.univie.ac.at allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: >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. 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@sophie.pri.univie.ac.at)