This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: howto use ramdrive to speed-up cygwin

I too would be interested in exploring this since I run cygwin and gcc on a laptop and the drive is fairly slow.

I would like to move /usr/include and /usr/src/x to a ramdrive so that access is faster.

Before working on a project I would simply rsync the files between the ramdrive and the persistant dir tree.

I used to do this many years ago and found that it could make a difference because include files were hit so often during a build. It works well on a system where caching is less effective. I tried some Windows ramdrives a while back but found them to destabilise my system.

Depending on memory constraints I'd be curious about playing some games to get /usr/bin moved there too....

Some basic info on how to create the ram drive (either within cygwin or using a reliable product outside of cygwin) would be useful. I tried creating an ext2fs using genext2fs but don't know how to mount it.

As for writing scripts to effectively use it and size it etc I can do.


Hans Horn wrote:

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
( 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.


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,

-- Unsubscribe info: Problem reports: Documentation: FAQ:


Diane & Dave
Fortune: The difference between America and England is that the
English think 100 miles is a long distance and the Americans
think 100 years is a long time.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]