[ On Wed, April 15, 1998 at 14:14:38 (-0700), Ross Harvey wrote: ]
> Subject: Re: Real vfork() (was: third results)
>
> I think vfork(2) can be evaluated quite favorably in cost-benefit terms:

And I think your thinking is extremely "self" centred.  By that I mean
that you're thinking in terms of BSD, or even NetBSD (or possibly even
unix in general).  In general terms this is not acceptable

I also don't think you're considering the true cost of porting
applications, and the subsequent maintenance costs such porting incurs,

Nor do I feel you are accurately measuring the performance benefit.  It
is certainly not "substantial" by my definition of that quantifier.

In fact I most certainly agree with Stefan that even a "substantial"
performance improvement (eg. >= 10%) is not worth the effort.  Jason
said "It shaves several seconds off a build of libc on my 200MHz PPro."
That's probably about 2%-4% at most (I've never timed a make in
src/lib/libc on similar equipment, but I do a full "make release" of
FreeBSD on a PII-266 in only 4.5 hours, and for those that don't know
FreeBSD this involves a "make install; cvs co; make build; make
distribution").  [BTW, 'make' is a bad example -- I'd rather see
something like lmbench used to test this so that we can eliminate
non-paging I/Os, and other factors.]

In my own personal opinion everything about vfork() is bad, even the
blocking of the parent (and in fact esp. that, since it's terribly
horrible to try and simulate in a non-vfork() environment without adding
code to the application).

I will admit that with xOpen/opengroup's "standard" definition of
vfork() things are not so bad as they could be w.r.t. application
portability, but without explicitly implementing *only* the lowest
common denominator it is *impossible* to force the average programmer to
adhere to only that lowest common denominator.

As an educated guess I will claim that I myself have personally spent
more time actually porting applications that make naughty use of vfork()
than I would ever have lost to even a 10% degradation in the performance
of those applications.  If we count the effort everyone has ever put
into doing the same, and we change the accounting to cost of maintenance
instead of pure time, then I think we could probably weigh fairly
against even all the time saved by all the people who've ever used
vfork() enable applications in a COW environment.  I even wasted a whole
day porting emacs (and testing, and reporting the changes to RMS, etc.) to
NetBSD back when NetBSD didn't have a "real" vfork()!

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>