help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: performance problems under CYGWIN


From: Warlich, Christof
Subject: RE: performance problems under CYGWIN
Date: Tue, 20 Sep 2011 09:58:28 +0200

David Boyce wrote:
> <address@hidden> wrote:
>> Can anyone give me a hint as to why the delay may occur after the two "child 
>> access "lines above?

> Sorry, I can't, but a few things:
> 
> - What version of GNU make are you using? It came up very recently
> that 3.82 has a bug which causes it to do exponentially more stat
> calls than 3.81. The person who caught the problem noticed it only
> because it slowed down his Cygwin builds dramatically - it hadn't had
> a noticeable effect on Linux. The bug is fixed in CVS so going either
> forward or backward from 3.82 should work. See
> http://lists.gnu.org/archive/html/bug-make/2011-09/msg00025.html
As I am using GNU make 3.82, this did sound rather promising, but no
luck: The latest CVS version did take exactly as long.
> 
> - Are you sure all file accesses are local (i.e. no SMB)?
Yes, they are. When I first tried the VM-build to check Gregs hint,
I did build on the shared VM folder, further increasing the delay by
a factor of 10. 
> 
> - There is an strace for cygwin which can show a timestamp for each
> system call. That should let you identify which one is causing the
> delay. But you have to be really careful with strace - although it
> Comes with Cygwin it's a native Win32 program, not a Cygwin program.
> This means it doesn't understand symlinks and so, on so it must be
> used with a no-symlink test case.
> 
> - Alternatively just instrument the code to do a binary search for the
> slow call. It looks like the "Child access" message is coming from the
> statement 'log_access (_("Child access"));' in the child_access()
> function which is called from jobs.c. Stick in some more logger calls
> till you narrow it down. And maybe modify the logger to add a time
> stamp.
Thanks for these hints, seems that I have to dig into this.
> 
> - Is this a pure Cygwin environment (Cygwin make, Cygwin shell, etc)?
Yes it is.
> 
> -David Boyce


reply via email to

[Prev in Thread] Current Thread [Next in Thread]