Message-ID: <465CC4A2.FA6D563A@dessent.net>
Date: Tue, 29 May 2007 17:26:10 -0700
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: howto use ramdrive to speed-up cygwin
References: <f3iemf$g97$1 AT sea DOT gmane DOT org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Hans Horn wrote:

> Could somebody give me a few pointers as to how to use/configure a
> ramdrive to speed-up cygwin.
> 
> There was a posting a few weeks ago
> (http://sourceware.org/ml/cygwin/2007-05/msg00121.html) in which Brian
> Dessent mentions that he is using a ramdrive for building gcc.
> 
> Brian, would you mind disclosing a few more details about this?

There's nothing really that exciting about what I did, it was mainly for
running the gcc testsuite that I was experimenting with ways to make the
time pass faster.  I noticed from both the HD light and from
sysinternals' FileMon that there was constant reading/seeking of the
xgcc under test, so I put the whole build directory on a ramdisk.

Obviously, you want to compress the ramdisk and you also have to either
have a lot of RAM or not build all languages.  Ada and Java in
particular will kill you, as they generate a ton of temporary binaries
when running the testsuite, and these all have full debug info by
default.  A full three stage bootstrap of all languages plus running the
testsuite currently occupies 7.45 GB in my build dir, so obviously you
have to do some paring down if you want to fit that all.  I can't
remember if I also moved /usr/bin onto the ramdrive or not.  I think I
did with a stripped down /usr/bin from a minimal install.  The mount
command makes it easy to relocate dirs physically but leave them in the
same location in the posix filespace.

You can also play around with removing -g from TARGET_CFLAGS and
"bootstrap-lean" to save space, but I don't remember if those helped or
not.  I remember getting a little frustrated that there were so many
different CFLAGS to specify and I was never able to get them all so as
to have the result be no bloating debug info.  Off the top of my head
there's something like:

BOOT_*FLAGS - for the stage 1 bootstrap
STAGE<n>_*FLAGS - for stage 2, 3
TARGET_*FLAGS - for the target libraries

...And then I think there's a few more nonstandard ones for the Ada
runtime and perhaps a couple more that I missed.  Alternatively there's
always LDFLAGS="-s" which might have been easier.  Anyway, getting back
on topic.

This is not a general purpose solution to speeding Cygwin up, it was
just for the particular purpose of running the testsuite, which current
takes for-frickin-ever because of whatever it is that dejagnu does that
causes every single spawn of a test to hit the disk.  You would think
the Windows system disk cache would kick in and prevent having to do
this sillyness, but it never did; the HD light never went out despite
spawning the same binaries over and over again time after time.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/