Today I was researching SSD options trying to find my perfect SSD when I stumbled upon this little post by Jeffrey Palermo. Basically, he tried several SSDs and came to conclusion that the incremental performance improvements given by SSDs do not justify their high cost. Instead he suggests... using a RAM drive! Now, for those of us who were computer users back in 5" diskette times, this may sound like a blast from the past but it actually makes a lot of sense.
The idea is to use RAM drive to store... the source code! And not just source code but entire solution workset, including the obj/Debug/Release folders and any third-party DLLs you reference. This may not sound like much but think what it does to your Visual Studio experience: not only all source files are always in RAM, immediately available to Visual Studio, C# compiler, and Resharper, but the results of the compilation are also stored in RAM which does miracles to multi-project solutions!
Now, you may worry about safety: what happens to my precious sources if machine needs to be restarted or the power goes down? Think about it: all source files are already stored in Source Control anyway. If you check-in moderately often (which is always a good idea from the perspective of Continuous Integration) you cannot loose more than a few hours of work. Besides, the tool Jeffrey recommends, freeware DataRam RAMDisk, can save the RAM drive to hardrive both on shutdown and at configured interval (I have mine set at 15 minutes) which makes the whole setup pretty damn safe.
The best news are saved for those who have integration tests hitting a local SQL Server database (as opposed to semi-compatible surrogates like SQLite which I had lots of problems with): according to my tests you can speed-up your integration tests 2-6 times! Indeed, in my case I saw a 6 times improvement, from 1+ hour down to 10 minutes! Although my setup is kind of stupid (I have entire database detached, copied over, and reattached for every single integration-test) but even your normal tests will breathe easier, believe me.
Now, if you happen to have a bunch of projects all over your hard drive, plus a few DB data folders, or even one huge source code folder that just won't fit in RAM, you may scratch your head, not willing to reorganize your entire workspace just to try out the new fad. My answer to that: use junction points. Indeed with juncpoints you can create a bunch of folders on your RAM drive and map each of them to a separate folder on your primary drive. This way you can only switch the most active of your projects to the RAM drive while keeping others on HDD.
Enough said, go and check it out. And never complain your builds are slow!
- Download and install DataRam RAMDisk
- Create a 2Gb RAM drive and leave it Unformatted. Watch out for memory consumption on your machine. On my 8Gb RAM machine I found 4Gb RAM drive putting too much stress on available memory, to the point where OS would swap a lot.
- Configure it to be saved on shutdown, loaded on startup, and saved on interval (say, every 15 minutes). Ideally you want the .img file to be stored on another physical hard drive, separate from the one your OS runs on. This way when RAM disk is saved (and it takes good 5 minutes to save 4GB!!!) it won't slow the entire system down.
- Start the RAM disk. This will fail the first time as the .img file won't yet exist but it will create it when you save the disk.
- Go to the Disk Manager, initialize the new "disk" and format it as NTFS
- Mount the disk as R:. Do not enable compression as that will kill the performance.
- Stop SQL Server, exit Visual Studio and quit any other programs that may access the folders you want to move to RAM drive
- Copy your IO-heavy folders to the RAM disk as required; I suggest mirroring the same structure on R: that you have on your C: drive. This way you always know which RAM folder corresponds to which physical drive folder.
- If you had custom permissions set on the original folders, they won't get copied. You will have to set them by hand
- Rename the original folders to something like .bak -- you can delete them later
- Create juncpoints to map original folder names to their new locations on R: drive. Do not use symlinks (the new feature of Vista intended to replace juncpoints) since the are in fact LESS transparent for Visual Studio. With symlinks, if you put your DLLs on the R: drive and add reference to your Visual Studio project, sometimes it may use the absolute R:\ path instead of the relative path causing build issues on the remote build server. With juncpoints, Visual Studio will happily use relative path.
- Start SQL Server, launch Visual Studio and enjoy!
Tags: