Re: [Fwd: Re: execv bug???]
Re: [Fwd: Re: execv bug???]
- Subject: Re: [Fwd: Re: execv bug???]
- From: Dave Zarzycki <email@hidden>
- Date: Mon, 28 Jan 2008 07:26:05 -0800
On Jan 28, 2008, at 4:28 AM, Jonas Maebe wrote:
On 28 Jan 2008, at 02:15, Peter Seebach wrote:
In message <email@hidden>,
Jonas Maebe wr
ites:
That's more or less true for Linux, but not for Mac OS X at least up
till 10.4.x (I haven't benchmarked on 10.5 yet). Compiling our
compiler with itself, which involves about 173 (v)fork+execs from a
single compiler run to assemble&link all the files, is 20% to 25%
slower with fork instead of vfork on a G4, and 35% to 40% on a G5
(32
bit processes in both cases) on 10.4.x. And for clarity: this is
relative to the entire time needed for compiling+assembling+linking
everything (on the G5: 24 vs 15 seconds), not some academic mbench-
like speed difference between the fork and vforks.
Yes. It does make a difference, but even so, the API is deprecated,
so even if this hurts performance a bit, it's still probably best to
avoid it whenever possible.
If it only hurt performance a bit I would never have changed the
code from using fork (which is what we used on all other *nix ports)
into using vfork in the first place. But a 25% to 40% slowdown
caused by 173 system calls in the process of compiling about 180
kloc is astronomical in my view.
Well, if performance really mattered, then multiple processes wouldn't
be used. Debating fork() versus vfork() is like debating whether you
can run faster with 10 or 20 pounds attached to your ankles. Either
way, you're going to run slower than the guy with no weights attached
to his ankles.
In any case, if you really want all sorts of forwards and backwards
compatibility, our dynamic linker APIs will let you, dynamically probe
the presence of posix_spawn. That will let you use the API, but
default back to vfork (or fork or whatever else you like) on older
releases.
davez
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden