Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!sunybcs!boulder!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtune!codas!killer!jfh
From: jfh@killer.UUCP (John Haugh)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: 98% in < 2s
Message-ID: <1634@killer.UUCP>
Date: Fri, 25-Sep-87 12:44:10 EDT
Article-I.D.: killer.1634
Posted: Fri Sep 25 12:44:10 1987
Date-Received: Sun, 27-Sep-87 09:58:32 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8579@utzoo.UUCP> <6886@eddie.MIT.EDU> <1351@homxc.UUCP>
Organization: Big "D" Home for Wayward Hackers
Lines: 21
Keywords: cost of bloated programs
Summary: fork() speed a factor
Xref: mnetor comp.arch:2373 comp.unix.wizards:4510 comp.os.misc:244


(Forget vfork() and how fast it is.  When AT&T adds it to System 5, then
I'll care about it. ;-)

I don't know how valid of a statement this is, but I have noticed that
to fork() a small program can often take as long as it takes to fork()
one twice as large (just as long being one of those subjective things ...)

I benchmarked kernels at my last emoployer and noticed that even the big
machines we tested (uVax, Plexus P/60's & P/75's, etc) didn't get past
40 or 50 forks per second.  The little programs seem to cost more than
the bigger ones in terms of forkability ...

Just rambling on ...

- John.
-- 
John F. Haugh II		HECI Exploration Co. Inc.
UUCP:	...!ihnp4!killer!jfh	11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?"	Dallas, TX. 75243
" ... Then Buy One!"		(214) 231-0993