howto use ramdrive to speed-up cygwin

[Hans Horn]

Brian Dessent wrote:
> 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
> 

Hi Brian,
thx for responding!

I wasn't aiming for building gcc ! Instead I was rather interested in 
the ramdisk aspect of that particular posting, and how I may be able to 
use the idea to perhaps speedup cygwin in general (speedier compilations 
are of course welcome!).

What ramdisk software did you use? Do you have some sort of automated 
setup that places /bin onto the ramdisk at boot time, and takes care of 
the appropriate mount?
In case my questions sound naiive - well, that's just what they are.
I'm simply trying to find ways to make things go faster.

thx again,
H.


--
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/