* Re: gmake is slow under cygwin
@ 2000-09-22 7:55 Earnie Boyd
2000-09-22 8:49 ` Bash + Shell hack = ? Luke Bakken
2000-09-25 2:49 ` gmake is slow under cygwin Gabriel Zachmann
0 siblings, 2 replies; 24+ messages in thread
From: Earnie Boyd @ 2000-09-22 7:55 UTC (permalink / raw)
To: Gabriel Zachmann, cygwin
--- 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Bash + Shell hack = ?
2000-09-22 7:55 gmake is slow under cygwin Earnie Boyd
@ 2000-09-22 8:49 ` Luke Bakken
2000-09-22 9:13 ` Jonathan M Merz
2000-09-22 22:55 ` Chris Abbey
2000-09-25 2:49 ` gmake is slow under cygwin Gabriel Zachmann
1 sibling, 2 replies; 24+ messages in thread
From: Luke Bakken @ 2000-09-22 8:49 UTC (permalink / raw)
To: egcs; +Cc: cygwin
Hi,
I've got an option for my "File Folder" file type so that if I right-click
on a folder, I can execute a cmd.exe prompt in that folder:
cmd.exe /K cd "%1"
What I'm wondering is if something analogous to the /K switch exists for
Bash, so that I can run a command before starting the login shell. the
"-c" option is similar, but the shell exits after running the command
specified. What I want is for it not to exit.
Thanks,
Luke
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Bash + Shell hack = ?
2000-09-22 8:49 ` Bash + Shell hack = ? Luke Bakken
@ 2000-09-22 9:13 ` Jonathan M Merz
2000-09-22 22:55 ` Chris Abbey
1 sibling, 0 replies; 24+ messages in thread
From: Jonathan M Merz @ 2000-09-22 9:13 UTC (permalink / raw)
To: Luke Bakken; +Cc: cygwin
[-- Attachment #1: Type: text/plain, Size: 2392 bytes --]
Hi,
I actually was trying to do the same thing a few weeks ago and came up with an ugly hack, but it gets the job done. The problem is that any time you run a bash --login, it drops you into your home directory, so you actually need to run the cd command _after_ starting the login shell. The way I managed this is to have a windows batch file call a bash shell script (since I'd rather write shell scripts than batch files) that creates a file containing the cd command to whatever the directory is. The two files for that are gotodir.bat and gotodir.sh (I've attached them). Then, I put a check in the bottom of my .bashrc and .profile to see if the file with the cd command exists, and if it does, execute it, then delete it (so that it won't be run if I just want to start a login shell in my home directory. So, to set it up (I warned you, this is ugly):
1. put gotodir.sh in your $HOME/bin directory (This can be changed, but you'll have to edit gotodir.bat to do it)
2. put gotodir.bat anywhere you like, just so you know where it is.
3. add the following to your .bashrc or .profile:
test -f ~/.chdirrc && . ~/.chdirrc
test -f ~/.chdirrc && rm ~/.chdirrc
4. in the windows registry, add:
[HKLM]\SOFTWARE\Classes\Folder\shell\Bash Prompt Here (Make this whatever you want to see in the context menu)
[HKLM]\SOFTWARE\Classes\Folder\shell\Bash Prompt Here\command
in the command key, add the string "c:\winnt\system32\cmd.exe /c <path to gotodir.bat>\gotodir.bat"
Hopefully I have the setup correct there. If not, let me know what's not working and hopefully I'll be able to correct myself. And if anyone knows of or can come up with a cleaner way to do this, please let us all know.
Hope it helps,
Jon
On Fri, Sep 22, 2000 at 08:48:04AM -0700, Luke Bakken wrote:
> Hi,
>
> I've got an option for my "File Folder" file type so that if I right-click
> on a folder, I can execute a cmd.exe prompt in that folder:
>
> cmd.exe /K cd "%1"
>
>
> What I'm wondering is if something analogous to the /K switch exists for
> Bash, so that I can run a command before starting the login shell. the
> "-c" option is similar, but the shell exits after running the command
> specified. What I want is for it not to exit.
>
> Thanks,
> Luke
>
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>
[-- Attachment #2: gotodir.bat --]
[-- Type: text/plain, Size: 59 bytes --]
REM ECHO OFF
bash %HOME%\bin\gotodir.sh
bash --login -i
[-- Attachment #3: gotodir.sh --]
[-- Type: text/plain, Size: 99 bytes --]
echo cd $PWD > $HOME/.chdirrc
echo rm .chdirrc >> $HOME/.chdirrc
echo clear >> $HOME/.chdirrc
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Bash + Shell hack = ?
2000-09-22 8:49 ` Bash + Shell hack = ? Luke Bakken
2000-09-22 9:13 ` Jonathan M Merz
@ 2000-09-22 22:55 ` Chris Abbey
1 sibling, 0 replies; 24+ messages in thread
From: Chris Abbey @ 2000-09-22 22:55 UTC (permalink / raw)
To: luke_bakken; +Cc: cygwin
If y'all don't mind I'd like to suggest a slightly cleaner way of doing this.
Starting from the windows explorer end. Windows automatically passes the fully
qualified path to the object as arg 1, so just create an item that points to
cygwin.bat however you wish, mine is called "bash this" and the command to run
is simply "d:\cygwin\cygwin.bat". Windows will automatically call it with the
full path, so if you choose this on c:\yada it would run "d:\cygwin\cygwin.bat
c:\yada".
Now to that we've got it into cygwin.bat we need to propagate it further, using
an environment variable is easiest... here's my cygwin.bat:
@set STARTIN=%1
@d:\cygwin\bin\bash --login -i
the only line there that is important to this is the one setting
the STARTIN envvar, as this is how we pass it on to bash... in order
to act on it I've replaced this line in /etc/profile:
cd $HOME
with this logic:
if [ ! -z "$STARTIN" ]; then
if [ -d "$STARTIN" ]; then
cd "$STARTIN"
else
echo "$STARTIN is not a valid path."
cd $HOME
fi
unset STARTIN
else
cd $HOME
fi
which also requires these lines to be changed, as . and ~ may no
longer be the same directory at this point in the script:
test -f ./.profile && . ./.profile
test -f ./.bashrc && . ./.bashrc
becomes:
test -f ~/.profile && . ~/.profile
test -f ~/.bashrc && . ~/.bashrc
This gives you a couple other advantages: such as you can create an icon
to open a bash prompt to any given location (I like one in my start bar
that automatically puts me in the root of my products build tree.) and
you can open a new bash window from any dos prompt with 'start cygwin .'
Note that if you want to be able to handle spaces in paths then you can
replace STARTIN's assignment with this:
set STARTIN=%1 %2 %3 %4 %5 %6 %7 %8 %9
which will allow you to have up to 8 spaces in the total path; the downside
to this is that the initial prompt will look a bit odd (trailing spaces)
until you cd the first time.
p.s. any relation to Kirby?
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
2000-09-22 7:55 gmake is slow under cygwin Earnie Boyd
2000-09-22 8:49 ` Bash + Shell hack = ? Luke Bakken
@ 2000-09-25 2:49 ` Gabriel Zachmann
1 sibling, 0 replies; 24+ messages in thread
From: Gabriel Zachmann @ 2000-09-25 2:49 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Gmake is slow under cygwin
@ 2001-03-12 14:54 Heribert Dahms
2001-03-12 15:03 ` John Pollock
0 siblings, 1 reply; 24+ messages in thread
From: Heribert Dahms @ 2001-03-12 14:54 UTC (permalink / raw)
To: 'John Pollock', cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Gmake is slow under cygwin
@ 2001-03-12 14:35 John Pollock
0 siblings, 0 replies; 24+ messages in thread
From: John Pollock @ 2001-03-12 14:35 UTC (permalink / raw)
To: cygwin
>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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Gmake is slow under cygwin
@ 2001-03-09 9:44 Marcus A Martin
2001-03-09 9:57 ` Larry Hall (RFK Partners, Inc)
2001-03-09 12:34 ` Jonathan Kamens
0 siblings, 2 replies; 24+ messages in thread
From: Marcus A Martin @ 2001-03-09 9:44 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Gmake is slow under cygwin
2001-03-09 9:44 Marcus A Martin
@ 2001-03-09 9:57 ` Larry Hall (RFK Partners, Inc)
2001-03-09 11:34 ` Marcus A Martin
2001-03-09 12:34 ` Jonathan Kamens
1 sibling, 1 reply; 24+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-03-09 9:57 UTC (permalink / raw)
To: Marcus A Martin, 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Gmake is slow under cygwin
2001-03-09 9:57 ` Larry Hall (RFK Partners, Inc)
@ 2001-03-09 11:34 ` Marcus A Martin
2001-03-09 11:44 ` Larry Hall (RFK Partners, Inc)
0 siblings, 1 reply; 24+ messages in thread
From: Marcus A Martin @ 2001-03-09 11:34 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Gmake is slow under cygwin
2001-03-09 11:34 ` Marcus A Martin
@ 2001-03-09 11:44 ` Larry Hall (RFK Partners, Inc)
2001-03-09 11:57 ` Chad Loder
0 siblings, 1 reply; 24+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-03-09 11:44 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Gmake is slow under cygwin
2001-03-09 11:44 ` Larry Hall (RFK Partners, Inc)
@ 2001-03-09 11:57 ` Chad Loder
2001-03-09 12:05 ` Marcus A Martin
0 siblings, 1 reply; 24+ messages in thread
From: Chad Loder @ 2001-03-09 11:57 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Gmake is slow under cygwin
2001-03-09 9:44 Marcus A Martin
2001-03-09 9:57 ` Larry Hall (RFK Partners, Inc)
@ 2001-03-09 12:34 ` Jonathan Kamens
1 sibling, 0 replies; 24+ messages in thread
From: Jonathan Kamens @ 2001-03-09 12:34 UTC (permalink / raw)
To: mmartin; +Cc: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: gmake is slow under cygwin
@ 2000-09-26 12:57 Scott Carter
2000-09-26 16:49 ` Chris Faylor
0 siblings, 1 reply; 24+ messages in thread
From: Scott Carter @ 2000-09-26 12:57 UTC (permalink / raw)
To: 'Gabriel Zachmann', cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
2000-09-26 12:57 gmake " Scott Carter
@ 2000-09-26 16:49 ` Chris Faylor
2000-09-26 20:56 ` Jeffrey Juliano
0 siblings, 1 reply; 24+ messages in thread
From: Chris Faylor @ 2000-09-26 16:49 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
2000-09-26 16:49 ` Chris Faylor
@ 2000-09-26 20:56 ` Jeffrey Juliano
2000-09-26 21:28 ` Chris Faylor
0 siblings, 1 reply; 24+ messages in thread
From: Jeffrey Juliano @ 2000-09-26 20:56 UTC (permalink / raw)
To: cygwin
--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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
2000-09-26 20:56 ` Jeffrey Juliano
@ 2000-09-26 21:28 ` Chris Faylor
2000-09-28 7:53 ` Jeffrey Juliano
2000-10-03 7:15 ` Fergus Henderson
0 siblings, 2 replies; 24+ messages in thread
From: Chris Faylor @ 2000-09-26 21:28 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
2000-09-26 21:28 ` Chris Faylor
@ 2000-09-28 7:53 ` Jeffrey Juliano
2000-10-03 7:15 ` Fergus Henderson
1 sibling, 0 replies; 24+ messages in thread
From: Jeffrey Juliano @ 2000-09-28 7:53 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
2000-09-26 21:28 ` Chris Faylor
2000-09-28 7:53 ` Jeffrey Juliano
@ 2000-10-03 7:15 ` Fergus Henderson
2000-10-03 8:27 ` Chris Faylor
1 sibling, 1 reply; 24+ messages in thread
From: Fergus Henderson @ 2000-10-03 7:15 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
2000-10-03 7:15 ` Fergus Henderson
@ 2000-10-03 8:27 ` Chris Faylor
0 siblings, 0 replies; 24+ messages in thread
From: Chris Faylor @ 2000-10-03 8:27 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: gmake is slow under cygwin
@ 2000-09-26 6:25 Earnie Boyd
0 siblings, 0 replies; 24+ messages in thread
From: Earnie Boyd @ 2000-09-26 6:25 UTC (permalink / raw)
To: Gabriel Zachmann, cygwin
--- 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
^ permalink raw reply [flat|nested] 24+ messages in thread
* gmake is slow under cygwin
@ 2000-09-22 2:41 Gabriel Zachmann
0 siblings, 0 replies; 24+ messages in thread
From: Gabriel Zachmann @ 2000-09-22 2:41 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2001-03-12 15:03 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-22 7:55 gmake is slow under cygwin Earnie Boyd
2000-09-22 8:49 ` Bash + Shell hack = ? Luke Bakken
2000-09-22 9:13 ` Jonathan M Merz
2000-09-22 22:55 ` Chris Abbey
2000-09-25 2:49 ` gmake is slow under cygwin Gabriel Zachmann
-- strict thread matches above, loose matches on Subject: below --
2001-03-12 14:54 Gmake " Heribert Dahms
2001-03-12 15:03 ` John Pollock
2001-03-12 14:35 John Pollock
2001-03-09 9:44 Marcus A Martin
2001-03-09 9:57 ` Larry Hall (RFK Partners, Inc)
2001-03-09 11:34 ` Marcus A Martin
2001-03-09 11:44 ` Larry Hall (RFK Partners, Inc)
2001-03-09 11:57 ` Chad Loder
2001-03-09 12:05 ` Marcus A Martin
2001-03-09 12:34 ` Jonathan Kamens
2000-09-26 12:57 gmake " Scott Carter
2000-09-26 16:49 ` Chris Faylor
2000-09-26 20:56 ` Jeffrey Juliano
2000-09-26 21:28 ` Chris Faylor
2000-09-28 7:53 ` Jeffrey Juliano
2000-10-03 7:15 ` Fergus Henderson
2000-10-03 8:27 ` Chris Faylor
2000-09-26 6:25 Earnie Boyd
2000-09-22 2:41 Gabriel Zachmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).