Shell Scripts v. Command Options (was: Re: small bug in who(1) of SVR3)

Leslie Mikesell les at chinet.chi.il.us
Thu Jan 17 02:52:34 AEST 1991


In article <18946 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:

>If you have more than 68 users on your system and it only forks 68 times
>per second, you are likely to find that shell scripts run pretty damned
>slow. 

After identifying the problem, why do you suggest throwing programming
effort at the symptoms rather than the cause?  There's no reason that
fork() needs to be slow, especially when called from a small executable
program.  There's even less reason for fork()/exec() combinations to
be slow since you know that most of the effort of the fork() is going
to be wasted, but that's another topic... 

>who | cut -d' ' -f1 | sort | pr -6 -l1
>will stop being fast *enough* the first time some collection of people
>start kicking off the other shell scripts the have replaced the other
>commands on the system.

Likewise, if you build sorting and output formatting into every
executable the system will slow down from loading all the extra
code.  And with less effort you could have designed a reasonable
memory management scheme instead (or a shell where cut, sort and
pr are built-in's if you like the kitchen-sink style).

Les Mikesell
  les at chinet.chi.il.us



More information about the Comp.bugs.sys5 mailing list