Subject: Re: [Boost-build] Extremely slow gcc launches on Cygwin
From: Terris Linenbach (terris_at_[hidden])
Date: 2010-08-18 15:47:41
Warning: this reply is related to Cygwin and is not related in any way to
gcc or boost, both of which I use (thanks to the many people who have cared
for this free software - I am very grateful).
We use cygwin perl. We find that Perl's exec function is very slow, even
without fork. An exec of, for example, perl.exe can easily take 15 seconds.
We run the same scripts on Windows and Linux on comparable hardware. What
takes 15 seconds on Linux (hundreds of system()'s and exec()'s) takes 3
minutes on Windows.
I understand the complexities of fork on Windows with copying memory and
duping filehandles - which is the reason why we use cygwin in the first
place. cygwin's implementation of fork is an impressive feat of software
I've done a bit of research on this topic. One of the conversations suggests
that bash's auto completion is to blame. I haven't gotten deep into it, but
you might want to try "copy ash.exe sh.exe" and see what happens. I guess
ash.exe is the old simpler sh.exe which now ships as a duplicate of
On Wed, Aug 18, 2010 at 11:43 AM, Emil Dotchevski
> It appears that on Cygwin bjam uses fork() to spawn a new instance of
> it when it launches gcc. I have 2 reasons to suspect that: 1) I see a
> second bjam.exe in Process Explorer and 2) while building a very very
> large Jamfile, every launch of gcc takes *forever*, which can be
> explained by the inefficient Cygwin fork() implementation (on Windows,
> fork() has to copy all of the memory that belongs to the process.)
> If my suspicion is correct, then my question is can the fork() be
> replaced by posix_spawn() or some such? If not, what could be causing
> the extremely slow gcc launches?
> Emil Dotchevski
> Reverge Studios, Inc.
> Unsubscribe & other changes:
-- http://twitter.com/TerrisLinenbach Sent from my Apple ][+
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk