Gmake is slow under cygwin

Gmake is slow under cygwin

[Marcus A Martin]

I am writting a build environment for a large progect. We use gmake to
compile or code on linux, SGI and windows 2k (via cygwin). While the build
environment can do all the preprocessing before a build very quickly on the
unix boxes, it can take up to 2 minutes on a windows box. This is a serious
diffence.

To give you an idea of what might be causing the problem, here is what our
make system does. When you execute make, it calls a find command to find all
the files called localdefs.mk. Each localdefs.mk file contains a list of
source files, defines the target as a library or an application, identifies
any exported headers, and then calls a make template. The make template
contains the rules on how everything is built. All of the localdefs.mk files
are processed in memory, then make begins the compilation of any file that
needs to be built.

The initial find takes 2-5 seconds but each localdefs.mk file takes 1-2
seconds to process in memory under a cygwin/windows box.  With about 150
libraries and applications, the time really adds up. Do you have any ideas
as to how I can accelerate the windows performance?

Thanks for the help,

Marcus

--------------------------------------------------------------
A program should follow the 'Law of Least Astonishment'.
What is this law?  It is simply that the program should
 always respond to the user in the way that astonishes him least.



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Gmake is slow under cygwin

[Larry Hall (RFK Partners, Inc)]

Check out the -x flag on mount.  It's not completely appropriate in general
but it has been noted to speed up performance by avoiding the need to open
files to check if they are executables.  On NTFS partitions, you can turn
on ntsec in the CYGWIN environment variable to get the same improvement more
appropriately.  See the user guide and the email archives in the last couple
of months that talk about both of these options, in regard to a similar issue
as a matter of fact.

Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



At 12:47 PM 3/9/2001, Marcus A Martin wrote:
>I am writting a build environment for a large progect. We use gmake to
>compile or code on linux, SGI and windows 2k (via cygwin). While the build
>environment can do all the preprocessing before a build very quickly on the
>unix boxes, it can take up to 2 minutes on a windows box. This is a serious
>diffence.
>
>To give you an idea of what might be causing the problem, here is what our
>make system does. When you execute make, it calls a find command to find all
>the files called localdefs.mk. Each localdefs.mk file contains a list of
>source files, defines the target as a library or an application, identifies
>any exported headers, and then calls a make template. The make template
>contains the rules on how everything is built. All of the localdefs.mk files
>are processed in memory, then make begins the compilation of any file that
>needs to be built.
>
>The initial find takes 2-5 seconds but each localdefs.mk file takes 1-2
>seconds to process in memory under a cygwin/windows box.  With about 150
>libraries and applications, the time really adds up. Do you have any ideas
>as to how I can accelerate the windows performance?
>
>Thanks for the help,
>
>Marcus
>
>--------------------------------------------------------------
>A program should follow the 'Law of Least Astonishment'.
>What is this law?  It is simply that the program should
>  always respond to the user in the way that astonishes him least.
>
>
>
>--
>Want to unsubscribe from this list?
>Check out: http://cygwin.com/ml/#unsubscribe-simple


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: Gmake is slow under cygwin

[Marcus A Martin]

I tried all of the suggestions in the email archives, but they did not help.
Are there any other suggestions?

Marcus

> -----Original Message-----
> From: cygwin-owner@sources.redhat.com
> [ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Larry Hall (RFK
> Partners, Inc)
> Sent: Friday, March 09, 2001 12:50 PM
> To: Marcus A Martin; cygwin@cygwin.com
> Subject: Re: Gmake is slow under cygwin
>
>
> Check out the -x flag on mount.  It's not completely appropriate
> in general
> but it has been noted to speed up performance by avoiding the need to open
> files to check if they are executables.  On NTFS partitions, you can turn
> on ntsec in the CYGWIN environment variable to get the same
> improvement more
> appropriately.  See the user guide and the email archives in the
> last couple
> of months that talk about both of these options, in regard to a
> similar issue
> as a matter of fact.
>
> Larry Hall                              lhall@rfk.com
> RFK Partners, Inc.                      http://www.rfk.com
> 118 Washington Street                   (508) 893-9779 - RFK Office
> Holliston, MA 01746                     (508) 893-9889 - FAX
>
>
>
> At 12:47 PM 3/9/2001, Marcus A Martin wrote:
> >I am writting a build environment for a large progect. We use gmake to
> >compile or code on linux, SGI and windows 2k (via cygwin). While
> the build
> >environment can do all the preprocessing before a build very
> quickly on the
> >unix boxes, it can take up to 2 minutes on a windows box. This
> is a serious
> >diffence.
> >
> >To give you an idea of what might be causing the problem, here
> is what our
> >make system does. When you execute make, it calls a find command
> to find all
> >the files called localdefs.mk. Each localdefs.mk file contains a list of
> >source files, defines the target as a library or an application,
> identifies
> >any exported headers, and then calls a make template. The make template
> >contains the rules on how everything is built. All of the
> localdefs.mk files
> >are processed in memory, then make begins the compilation of any
> file that
> >needs to be built.
> >
> >The initial find takes 2-5 seconds but each localdefs.mk file takes 1-2
> >seconds to process in memory under a cygwin/windows box.  With about 150
> >libraries and applications, the time really adds up. Do you have
> any ideas
> >as to how I can accelerate the windows performance?
> >
> >Thanks for the help,
> >
> >Marcus
> >
> >--------------------------------------------------------------
> >A program should follow the 'Law of Least Astonishment'.
> >What is this law?  It is simply that the program should
> >  always respond to the user in the way that astonishes him least.
> >
> >
> >
> >--
> >Want to unsubscribe from this list?
> >Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: Gmake is slow under cygwin

[Larry Hall (RFK Partners, Inc)]

Beyond debug it, I have none.  Keep in mind that Cygwin is always going to 
be slower, since its an emulated environment.  That said, not allot of effort
has been put into performance issues so far.

Larry


At 02:37 PM 3/9/2001, Marcus A Martin wrote:
>I tried all of the suggestions in the email archives, but they did not help.
>Are there any other suggestions?
>
>Marcus
>
> > -----Original Message-----
> > From: cygwin-owner@sources.redhat.com
> > [ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Larry Hall (RFK
> > Partners, Inc)
> > Sent: Friday, March 09, 2001 12:50 PM
> > To: Marcus A Martin; cygwin@cygwin.com
> > Subject: Re: Gmake is slow under cygwin
> >
> >
> > Check out the -x flag on mount.  It's not completely appropriate
> > in general
> > but it has been noted to speed up performance by avoiding the need to open
> > files to check if they are executables.  On NTFS partitions, you can turn
> > on ntsec in the CYGWIN environment variable to get the same
> > improvement more
> > appropriately.  See the user guide and the email archives in the
> > last couple
> > of months that talk about both of these options, in regard to a
> > similar issue
> > as a matter of fact.
> >
> > Larry Hall                              lhall@rfk.com
> > RFK Partners, Inc.                      http://www.rfk.com
> > 118 Washington Street                   (508) 893-9779 - RFK Office
> > Holliston, MA 01746                     (508) 893-9889 - FAX
> >
> >
> >
> > At 12:47 PM 3/9/2001, Marcus A Martin wrote:
> > >I am writting a build environment for a large progect. We use gmake to
> > >compile or code on linux, SGI and windows 2k (via cygwin). While
> > the build
> > >environment can do all the preprocessing before a build very
> > quickly on the
> > >unix boxes, it can take up to 2 minutes on a windows box. This
> > is a serious
> > >diffence.
> > >
> > >To give you an idea of what might be causing the problem, here
> > is what our
> > >make system does. When you execute make, it calls a find command
> > to find all
> > >the files called localdefs.mk. Each localdefs.mk file contains a list of
> > >source files, defines the target as a library or an application,
> > identifies
> > >any exported headers, and then calls a make template. The make template
> > >contains the rules on how everything is built. All of the
> > localdefs.mk files
> > >are processed in memory, then make begins the compilation of any
> > file that
> > >needs to be built.
> > >
> > >The initial find takes 2-5 seconds but each localdefs.mk file takes 1-2
> > >seconds to process in memory under a cygwin/windows box.  With about 150
> > >libraries and applications, the time really adds up. Do you have
> > any ideas
> > >as to how I can accelerate the windows performance?
> > >
> > >Thanks for the help,
> > >
> > >Marcus
> > >
> > >--------------------------------------------------------------
> > >A program should follow the 'Law of Least Astonishment'.
> > >What is this law?  It is simply that the program should
> > >  always respond to the user in the way that astonishes him least.
> > >
> > >
> > >
> > >--
> > >Want to unsubscribe from this list?
> > >Check out: http://cygwin.com/ml/#unsubscribe-simple
> >
> >
> > --
> > Want to unsubscribe from this list?
> > Check out: http://cygwin.com/ml/#unsubscribe-simple
> >
> >
>
>
>--
>Want to unsubscribe from this list?
>Check out: http://cygwin.com/ml/#unsubscribe-simple


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: Gmake is slow under cygwin

[Chad Loder]

Yeah, our GNU make system is a bit slower than on UNIX.
It's definitely the file/directory I/O that's creating
the overhead -- I've taken the approach of trying to
optimize the makefiles themselves, minimizing the
number of file I/O operations make will have to do.

I got a modest performance increase by turning off
GNUMake's magical "auto remake the makefiles if necessary"
behavior...

         c

At 02:38 PM 3/9/2001 -0500, you wrote:

>Beyond debug it, I have none.  Keep in mind that Cygwin is always going to
>be slower, since its an emulated environment.  That said, not allot of effort
>has been put into performance issues so far.
>
>Larry



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: Gmake is slow under cygwin

[Marcus A Martin]

> 
> I got a modest performance increase by turning off
> GNUMake's magical "auto remake the makefiles if necessary"
> behavior...
> 

How do you do this.

Marcus

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Gmake is slow under cygwin

[Jonathan Kamens]

Here are the changes we've made recently to our build environment to
speed up builds with GNU Make under Cygwin....

1) Enabled the "exec" option on nearly all of our cygwin mount
   points.

2) Call Make with "-r" to disable all predefined rules.  If you use
   any of the predefined rules in your builds, you can simply define
   them explicitly in your templates.

   This is significant because the predefined rules do things like
   cause Make to look for RCS and SCCS files corresponding to every
   single dependency file.  All of these unnecessary file accesses
   slow things down significantly.

   I believe that one of the predefined rules disabled by "-r" is the
   "rebuild Makefile automatically" predefined rule that somebody else
   mentioned.

3) Put "SHELL=/bin/sh" in our Makefile templates.  This has two
   effects:

   a) Without it, Make searches for "sh.exe" in its search path.  The
      file accesses necessary to find "sh.exe" are significant,
      especially when your build system uses a number of invocations
      of Make rather than doing everything in a single Make process (I
      couldn't tell which of these models you use).

   b) Make optimizes away the command "/bin/sh -c :" so that a shell
      never actually gets spawned, but only that *exact* command.  For
      example, "sh.exe -c :" does *not* get optimized away.  If you
      have lots of rules which use the empty command ":" as a
      placeholder (and we do), this optimization is important.

We also set the CYGWIN environment variable to "binmode tty" for all
of our users and builds.  I don't know whether "binmode" has any
effect on performance; I suppose it's possible that it does.

Finally, we did some Windows NT performance tweaking, some of which
might also be applicable on Windows NT.  Perhaps my colleague John
Pollack, who did that work, can provide more details :-).

To find out what's hogging resources in your Make, run "strace make"
instead of "make", with stdout and stderr redirected into a log file
(which will end up being quite large).  Then read through the log file
and you can see what Make is actually doing.  Look in particular at
file operations like "stat" and process forks ("spawn").  This may
give you some clues about what you can optimize.  This enabled us to
eliminate a large number of unnecessary file operations and speed up
our builds significantly.

  jik

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: Gmake is slow under cygwin

[Heribert Dahms]

Hi John,

can you please check the URL? I get "Not found",
also for http://www.mga.au.com/presentations/tune_nt
and http://www.mga.au.com/presentations
and there seems no search feature either...

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	John Pollock [SMTP:jpollock@curl.com]
> Sent:	Monday, March 12, 2001 23:35
> To:	cygwin@sourceware.cygnus.com
> Subject:	Re: Gmake is slow under cygwin
> 
	[Heribert]  [snip]

> - Stop NT from recording the LastAccessTimeStamp for every file accessed.
> ( http://www.mga.au.com/presentations/tune_nt/tsld039.htm ).  Most of the
> time you
> don't need this info, and when many files are touched in a short burst
> (i.e.
> during make) this change can help.
> 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: Gmake is slow under cygwin

[John Pollock]

> can you please check the URL? I get "Not found",
> also for http://www.mga.au.com/presentations/tune_nt
> and http://www.mga.au.com/presentations
> and there seems no search feature either...

Hmmm...that page was available last week!  Oh well.

In any case, what you need to change is 
HKLM\System\CurrentControlSet\Control\FileSystem

add a DWORD value called NtfsDisableLastAccessUpdate with value 1.

Cheers,
john

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Gmake is slow under cygwin

[John Pollock]

>Finally, we did some Windows NT performance tweaking, some of which
>might also be applicable on Windows NT.  Perhaps my colleague John
>Pollack, who did that work, can provide more details :-).

Oh, you mean me -- i never realized i spelled my name wrong.  ;)

The single-largest performance enhancement we made was to start using
the -j2 job flag (since our machines are dual-CPUs).  This knocked about
1/2 hour off the build time, a 30-40% improvement, although has had the side
effect of occasionally causing make to hang (see jonathan's earlier emails on
this subject).  However, in terms of tweaks, i employed some registry hacks
which knocked another 15 or so minutes off the total build time (these hacks all
appear to work for Win2k as well).

**NOTE**: these are all "caveat emptor"; they may help your situation, but you
should employ them one at a time and gauge a) their effectiveness for you, and
b) their stability (optimizing memory utilization can be somewhat dangerous).
Use them carefully, especially the first two below!

- Change the IoPageLockLimit to a more reasonable setting (see
http://www.jsiinc.com/TIP0100/rh0155.htm ).  This allows intensive I/O operations
to take better advantage of more memory, if it exists. In our case, our build
servers have 1GB of RAM, so there's quite a bit to take advantage of.  But you
have to be careful doing this; if you extend the value beyond the limits of
physical memory your machine can become unstable (the article outlines this, i
think, and gives guidelines as to what values to set depending on how much RAM
you have)

- Enable LargeSystemCache.  For machines with a lot of RAM this enables Windows
to create a larger system cache using available physical memory, which can speed
up both I/O and file operations.

- Stop NT from recording the LastAccessTimeStamp for every file accessed.
( http://www.mga.au.com/presentations/tune_nt/tsld039.htm ).  Most of the time you
don't need this info, and when many files are touched in a short burst (i.e.
during make) this change can help.

- create a secondary pagefile on a different partition (preferably a different
physical drive) than the partition containing the build directory.  NT/Win2k are
programmed to determine which pagefile is most optimal to use (i.e. on the
partition least involved in I/O).

- Use Windows 2000 instead of Windows NT.  i haven't figured out why yet, but
our overall build time has been reduced about 10-15 minutes via this change.  It
may be because SP3 for NT 4.0 changed the way that the general memory heap was
allocated in a sub-optimal way, and Win2k doesn't have this problem.

In addition, i've considered stopping the NTExecutive from paging to disk
altogether.  Some device drivers will page to disk even if they don't need to;
it's just the way they were written.  But i haven't tried this yet, and doubt it
would have a huge impact on our build times.

Cheers,
John


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: gmake is slow under cygwin

[Scott Carter]

I haven't had this problem in my makefiles, but yesterday I happened to be
trying out a makefile that someone else sent me, and I experienced a *huge*
delay. I haven't tried to analyze it, but I did observe this. When the VPATH
is set to any of the following (which, by the way, don't work correctly in
the test makefile) 

VPATH = c:/temp/test/source
VPATH = /cygdrive/c/temp/test/source
VPATH = //c/temp/test/source

There is no long delay. When VPATH is set to this (which is incorrect)

VPATH = //cygdrive/c/temp/test/source

and I do 

make -d

make spits out
-----------------------------------
GNU Make version 3.79, by Richard Stallman and Roland McGrath.
Built for i686-pc-cygwin
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug-make@gnu.org>.

Reading makefiles...
Reading makefile `makefile'...
-----------------------------------

and then stalls for about 7 seconds before continuing. I have no idea if you
have a bad VPATH in your makefiles, but this example illustrates that some
errors can cause large delays, and yet otherwise not be reported as errors.

I don't know if any of the following suggestions will appreciably speed up
processing, but I know they relieve make of having to examine a lot of
dead-end possibilities. [NOTE that these may not be desirable/usable in all
circumstances.]

1) Use .PHONY: for all targets that don't correspond to real files.
2) Use .SUFFIXES:#blank to delete all known default suffixes.
3) Add an empty rule (no dependencies, no commands) for "makefile" and any
files it includes.

Good luck
Scott Carter
Software Engineer

-----Original Message-----
From: Gabriel Zachmann [ mailto:zach@igd.fhg.de ]
Sent: Monday, September 25, 2000 03:49 AM
To: cygwin@sources.redhat.com
Subject: Re: gmake is slow under cygwin


] --- Gabriel Zachmann <zach@igd.fhg.de> wrote:
] > 
] > Any ideas or insights will be highly appreciated,
] > Gab.
] > 
] 
] Any virus scanners running?  See the FAQ.
] 

(Hm, the FAQ didn't say that a virus scanner could incur a performance
penalty, it just said that it might prevent cygwin from functioning ;-)

Ok, I switched McAffee off.
But that reduced execution time only by about 1 sec:
-  with mcaffee running: real time = 7.4 sec, user time = 3.1 sec;
-  mcaffee not running: real = 6 sec, user time = 2.8 sec

That still seems pretty slow for just a few 100 lines of makefiles,
doesn't it?

Cheers,
Gab.


-- 
/---------------------------------------------------------------------\
| Paradigm is a word too often used by those                          |
| who would like to have a new idea                                   |
| but cannot think of one.                                            |
|                     (Mervyn King, Deputy Governor, Bank of England) |
|                                                                     |
| zach@igd.fhg.de          gab@gab.cx        Gabriel.Zachmann@gmx.net |
| www.igd.fhg.de/~zach/    www.gab.cx        __@/'                    |
\---------------------------------------------------------------------/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Chris Faylor]

On Tue, Sep 26, 2000 at 01:57:40PM -0600, Scott Carter wrote:
>I haven't had this problem in my makefiles, but yesterday I happened to be
>trying out a makefile that someone else sent me, and I experienced a *huge*
>delay. I haven't tried to analyze it, but I did observe this. When the VPATH
>is set to any of the following (which, by the way, don't work correctly in
>the test makefile) 
>
>VPATH = c:/temp/test/source
>VPATH = /cygdrive/c/temp/test/source
>VPATH = //c/temp/test/source
>
>There is no long delay. When VPATH is set to this (which is incorrect)
>
>VPATH = //cygdrive/c/temp/test/source

Hmm.  I can see why that would cause a huge delay.  This is a very good
point.  Thanks for bringing it up.

I can easily see someone translating //c to //cygdrive/c and seeing the
delay the you describe.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Jeffrey Juliano]

--On Tuesday, September 26, 2000 Chris Faylor <cgf@cygnus.com> wrote:
> On Tue, Sep 26, 2000 at 01:57:40PM -0600, Scott Carter wrote:
>> There is no long delay. When VPATH is set to this (which is incorrect)
>>
>> VPATH = //cygdrive/c/temp/test/source
>
> Hmm.  I can see why that would cause a huge delay.  This is a very good
> point.  Thanks for bringing it up.
>
> I can easily see someone translating //c to //cygdrive/c and seeing the
> delay the you describe.

Would it make sense to treat `//cygdrive/[a-zA-Z]' as a special case 
prefix, and not try to actually find a machine named `cygdrive'?  I suspect 
this is the direction Chris was thinking.  Of course, the special case 
logic would have to honor the customizable cygdrive prefix.

Looks like, currently, you're allowed to double-up slashes anywhere except 
for the first slash.  e.g. `/usr//local' but not `//usr/local'.  That's not 
commensurate with other unix systems I've tested.

My proposed change would make path handling even less symmetric, so perhaps 
it's not a good idea afterall.  Is this even worth discussing?

-jeff


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Chris Faylor]

On Tue, Sep 26, 2000 at 11:55:27PM -0400, Jeffrey Juliano wrote:
>--On Tuesday, September 26, 2000 Chris Faylor <cgf@cygnus.com> wrote:
>> On Tue, Sep 26, 2000 at 01:57:40PM -0600, Scott Carter wrote:
>>> There is no long delay. When VPATH is set to this (which is incorrect)
>>>
>>> VPATH = //cygdrive/c/temp/test/source
>>
>> Hmm.  I can see why that would cause a huge delay.  This is a very good
>> point.  Thanks for bringing it up.
>>
>> I can easily see someone translating //c to //cygdrive/c and seeing the
>> delay the you describe.
>
>Would it make sense to treat `//cygdrive/[a-zA-Z]' as a special case 
>prefix, and not try to actually find a machine named `cygdrive'?  I suspect 
>this is the direction Chris was thinking.  Of course, the special case 
>logic would have to honor the customizable cygdrive prefix.

No.  I wasn't thinking that way at all.  If someone wants to use //cygdrive
as a machine name I'm not going to stop them.

>Looks like, currently, you're allowed to double-up slashes anywhere except 
>for the first slash.  e.g. `/usr//local' but not `//usr/local'.  That's not 
>commensurate with other unix systems I've tested.

You're not running on UNIX.  You're running on Windows.  That means that
you have a filesystem which is (by default) case preserving but case
insensitive.  You can't create filenames with ':' or '\' in them.  There
are special files called "aux", "com1", "com2", "prn", "lpt1", etc.

We could work around all of those problems with some kind of kludge or
other but I don't think it is a good idea at all.  It would complicate file
parsing for, IMO, little gain.  The net result would be that you'd have
files that were only usable under Cygwin and we'd constantly be explaining
that fact.

So, I'm not going to stop Cygwin from interpreting the leading double
slash or backslash the same way as Windows.  It's part of Windows
proscribed method for accessing remote shares and AFAIK, it's not
improper to treat two leading slashes as "special" anyway.  Windows is
not the only OS which has this distinction.

>My proposed change would make path handling even less symmetric, so perhaps 
>it's not a good idea afterall.  Is this even worth discussing?

No, I don't think so.  I'm not really going to be swayed on this issue.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Jeffrey Juliano]

On Wed, Sep 27, 2000 at 12:27 AM -0400, Chris Faylor wrote:

> On Tue, Sep 26, 2000 at 11:55:27PM -0400, Jeffrey Juliano wrote:

>> My proposed change would make path handling even less symmetric, so
>> perhaps  it's not a good idea afterall.  Is this even worth discussing?
>
> No, I don't think so.  I'm not really going to be swayed on this issue.

Agreed.  Especially after finding the thread "File name syntax (WAS: RE: 
FW: Can not config sshd)", which I had not previously read.  Sorry to bring 
it up again.

In that thread, Chris points out that a leading double-slash is allowed to 
be handled as a special case, and there are unix systems that do so.  I 
guess that means that any code that doesn't take this into account is 
broken anyway a portability standpoint.

-jeff


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Fergus Henderson]

On 27-Sep-2000, Chris Faylor <cgf@cygnus.com> wrote:
> AFAIK, it's not improper to treat two leading slashes as "special" anyway.

I thought I had heard that one of the POSIX standards (ISO/IEC 9945-1:1990,
I think) prohibited that?

Unfortunately I don't have a copy of the relevant standard on hand to
check it.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Chris Faylor]

On Wed, Oct 04, 2000 at 01:15:52AM +1100, Fergus Henderson wrote:
>On 27-Sep-2000, Chris Faylor <cgf@cygnus.com> wrote:
>> AFAIK, it's not improper to treat two leading slashes as "special" anyway.
>
>I thought I had heard that one of the POSIX standards (ISO/IEC 9945-1:1990,
>I think) prohibited that?
>
>Unfortunately I don't have a copy of the relevant standard on hand to
>check it.

Searching opengroup.org, I came across this:

 "A path name that begins with two successive slashes may be
 interpreted in an implementation-dependent manner,
 although more than two leading slashes shall be treated as a
 single slash."

I don't have a specific reference, unfortunately.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Earnie Boyd]

--- Gabriel Zachmann <zach@igd.fhg.de> wrote:
> ] --- Gabriel Zachmann <zach@igd.fhg.de> wrote:
> ] > 
> ] > Any ideas or insights will be highly appreciated,
> ] > Gab.
> ] > 
> ] 
> ] Any virus scanners running?  See the FAQ.
> ] 
> 
> (Hm, the FAQ didn't say that a virus scanner could incur a performance
> penalty, it just said that it might prevent cygwin from functioning ;-)
> 
> Ok, I switched McAffee off.
> But that reduced execution time only by about 1 sec:
> -  with mcaffee running: real time = 7.4 sec, user time = 3.1 sec;
> -  mcaffee not running: real = 6 sec, user time = 2.8 sec
> 
> That still seems pretty slow for just a few 100 lines of makefiles,
> doesn't it?
> 

You don't say what you're executing, but doing `/bin/time -v ls -l /bin' I get:
        Command being timed: "ls -l /bin"
        User time (seconds): 0.45
        System time (seconds): 0.29
        Percent of CPU this job got: 17%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:04.21
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 0
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 0
        Voluntary context switches: 0
        Involuntary context switches: 0
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0
So it appears to be you're setup.  I'm using NT4sp4, Cygwin-1.1.4.  The output
of `cygcheck -s -r -v' pasted in a mail and sent to the list might be useful.

Cheers,

=====
--- < http://earniesystems.safeshopper.com > ---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Earnie Boyd]

--- Gabriel Zachmann <zach@igd.fhg.de> wrote:
> 
> Any ideas or insights will be highly appreciated,
> Gab.
> 

Any virus scanners running?  See the FAQ.

Cheers,

=====
--- < http://earniesystems.safeshopper.com > ---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gmake is slow under cygwin

[Gabriel Zachmann]

] --- Gabriel Zachmann <zach@igd.fhg.de> wrote:
] > 
] > Any ideas or insights will be highly appreciated,
] > Gab.
] > 
] 
] Any virus scanners running?  See the FAQ.
] 

(Hm, the FAQ didn't say that a virus scanner could incur a performance
penalty, it just said that it might prevent cygwin from functioning ;-)

Ok, I switched McAffee off.
But that reduced execution time only by about 1 sec:
-  with mcaffee running: real time = 7.4 sec, user time = 3.1 sec;
-  mcaffee not running: real = 6 sec, user time = 2.8 sec

That still seems pretty slow for just a few 100 lines of makefiles,
doesn't it?

Cheers,
Gab.


-- 
/---------------------------------------------------------------------\
| Paradigm is a word too often used by those                          |
| who would like to have a new idea                                   |
| but cannot think of one.                                            |
|                     (Mervyn King, Deputy Governor, Bank of England) |
|                                                                     |
| zach@igd.fhg.de          gab@gab.cx        Gabriel.Zachmann@gmx.net |
| www.igd.fhg.de/~zach/    www.gab.cx        __@/'                    |
\---------------------------------------------------------------------/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

gmake is slow under cygwin

[Gabriel Zachmann]

Does some kind soul have any idea,
why gmake (3.79) is so slow under cygwin (vers 1.1.4).
The machine is a dual P3/600MHz with Windows2000.
All the makefiles are on a local drive (about 800 lines total),
and I'm making a very simple target, which just prints some makefile
variables.

Maybe the problem is not gmake itself, mnaybe it's cygwin,
maybe its win2000, maybe ...

What's funny is that cygwin's 'time' command tells me that, for instance,
user time is only 1.5 sec but real time is 10 sec!
But on our unix boxes (which have slower processors) make is much faster.

I have one target, which just echo's some 20 makefile variables,
and one can actually *see* each line being echo'ed ...

The cygwin installation itself was done with the setup.exe,
and I don't recall any problems or err messages.

Any ideas or insights will be highly appreciated,
Gab.

-- 
/---------------------------------------------------------------------\
| What if you slept?  And what if, in your sleep, you dreamed?        |
| And what if, in your dream, you went to heaven and there plucked a  |
| strange and beautiful flower?  And what if, when you awoke,         |
| you had the flower in your hand?  Ah, what then?        (Coleridge) |
|                                                                     |
| zach@igd.fhg.de          gab@gab.cx        Gabriel.Zachmann@gmx.net |
| www.igd.fhg.de/~zach/    www.gab.cx        __@/'                    |
\---------------------------------------------------------------------/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com