Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!magnus.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.bugs.sys5
Subject: Re: Shell Scripts v. Command Options (was: Re: small bug in who(1) of SVR3)
Message-ID: <1249:Jan1811:37:3991@kramden.acf.nyu.edu>
Date: 18 Jan 91 11:37:39 GMT
References: <18899@rpp386.cactus.org> <1991Jan14.202053.20054@zoo.toronto.edu> <18946@rpp386.cactus.org>
Organization: IR
Lines: 18

In article <18946@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> As for performance, benchmarks will indicate the fork() is an extremely
> expensive system call.  When I was a Pinnacle Systems, one of my jobs was
> to perform benchmarks on competitors equipment.  The average system that
> I evaluated fork()'d less than 100 times per second, with many well below
> 30 or 40.  A certain 3 letter company's product fork'd about 20 times
> per second.

Your test is extremely misleading. On one system I manage, the page size
is 64K, and practically every executable is at least two pages. Guess
what? fork() takes a *noticeable* amount of real time, simply because
the machine spends so long loading from disk. But with several users
running programs from several different disks, everything overlaps
nicely and the total time spent is relatively small. I suspect the same
is true of the systems you test---every fork() takes 30 or 50 ms, but
many of them can overlap at once.

---Dan