February 1. 2009 11:44

It's all fun and games until the power goes out.
Yep, but that's true even in a situation where you just have an unsaved document. Sure, RAM is volatile, but you can easily sync the RAM with a folder on a hard drive, or do a commit to a source control repository. Oh, and there's also things like UPS that can give you time to save your work.
So the project size has to be less than 128 Mb. Is it practical to load big projects in to this disk?
Actually, this is just a number I've chosen based on what the particular RAM Disk software allows me to do. There are other, commercial RAM Disk programs out there that might not have this limitation.

dmitri

February 1. 2009 16:10

Well you'd still have to sync them. Is there a way to make a RAM disk work like a cache, i.e. load a certain directory, caching the load time (which is the heavy part of VS) and saving directly to that directory?

Umm, that's exactly what happens (I think). Here's what I do: I have a Subversion repository on a remote computer; I do a checkout onto the RAM drive and then work with that. If I wanted to, I could also set up SyncToy or similar program to cache the solution on the local hard drive. But I don't, because it's unnecessary. Since I have my own repository, I can commit as often as I want.

One thing I want to point out is that the RAM drive program I use is very stable, meaning that I've never had anything go wrong. And since I hardly ever switch off my machine, I almost always have the snapshot of my work in RAM.

Performance-wise, the results are quite dramatic: the typical "Hello World" program compiles a lot faster when running off RAM. It levels off somewhat when you have multi-project solutions (due to dependencies and such), but it is still way faster than having VS work off a hard disk. Oh, and if you work with code generation (e.g., CodeGenUtils, DSL Tools, T4, and such), the difference in speed is quite dramatic.

dmitri

February 1. 2009 23:10

Actually, from what I know, 64-bit RAM drive emulation is a lot more difficult. I doubt you could find free software for a 64-bit system. Of course, there are inherent advantages to 64-bit (addressable memory), but I would also consider using something like Gigabyte iRAM (is it still being sold?) if you need to use very large solutions.

And, of course, large amounts of RAM can be used for other, equally useful things - such as in-depth static analysis or searching for duplicates within large code bases.

Extra processors also help in this regard.

dmitri

February 2. 2009 18:55

Well, some of us don't have their own repositories that they can check in to at any time. Or very stable computers - mine at work reboots daily and I don't even know why.
That sucks... for a number of reasons. Having to work on an unstable machine is something that I for one find completely unacceptable (just as working on a slow one).
Re 64bits, wow64.exe should be able to run the 32 bit program without problems.
This isn't a user-mode program we're talking about. There's no 'emulation' possible - the driver has to be perfect and take care of all 64-bit nuances. No small feat.

dmitri

February 9. 2009 22:13

I wouldn't want to have a 5-10gig code base to begin with :)

dmitri