Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.bugs.sys5
Subject: Re: Shell Scripts v. Command Options (was: Re: small bug in who(1) of SVR3)
Message-ID: <1991Jan16.155234.4149@chinet.chi.il.us>
Date: 16 Jan 91 15:52:34 GMT
References: <18899@rpp386.cactus.org> <1991Jan14.202053.20054@zoo.toronto.edu> <18946@rpp386.cactus.org>
Organization: Chinet - Public Access UNIX
Lines: 26

In article <18946@rpp386.cactus.org> jfh@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@chinet.chi.il.us