Hello,
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 engineering.
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 bash.exe.
Best,
Terris
On Wed, Aug 18, 2010 at 11:43 AM, Emil Dotchevski
<emil@revergestudios.com> wrote:
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?
Thanks,
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
--
http://twitter.com/TerrisLinenbachSent from my Apple ][+