site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 28 Jan 2008, at 04:23, Jordan K. Hubbard wrote: n Jan 27, 2008, at 2:46 PM, Jonas Maebe wrote: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. It would be interesting to benchmark this in 10.5 as well, given a number of changes to the relevant code, I don't have a PPC with 10.5 yet, but I'll try when I have the chance. I'll also check fork vs vfork on my MacBook (which can only run 10.5). but the original poster who noted that vfork() was deprecated was correct. At some point, I would not be at all surprised to see a "#define vfork fork" in unistd.h so that code path can be deprecated entirely. What about backwards compatibility for already compiled binaries? Since libSystem is not a framework, I'm not sure how this can be ascertained should vfork also be removed from the library itself. This email sent to site_archiver@lists.apple.com