Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: "John Pollock" <jpollock AT curl DOT com>
To: <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: Gmake is slow under cygwin
Date: Mon, 12 Mar 2001 17:35:23 -0500
Message-ID: <NEBBJPGNBOKKDAEIIMIKOEHNCEAA.jpollock@curl.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

>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