I have a VS 2005 solution with 19 projects.In total it consumes ~600MB of disk space (entire solution folder, including binaries). Needless to say that build times are relatively high. They are high even though my workstation has 4GB of RAM, RAID 0+1 7200rpm disks, 4GB ReadyBoost USB key and Core 2 Duo 6600.
The bottleneck in my situation is definitely disk I/O – building a solution results in plenty of reads and even more writes. The logical choice would be buying WD Raptor disks that spin at 10,000rpm. It should reduce build times somehow. However, there is another solution that reduces build times dramatically. Literally.
It is called RAM disk. Instead of working with files residing on physically disk, you work with files residing in RAM.
Here are the pros:
- latency is almost non existing
- nothing beats transfer speed (RAM to RAM)
- build times are reduced dramatically
Nothing has only good sides, even RAM disks don’t:
- files are not persistent. IOW if your computer experiences blue screen you can say goodbye to the files on RAM disk
Let’s dig into this problem. First, a serious workstation shouldn’t experience blue screens at all. My Vista is pretty stable and I don’t see blue screens. Next, you can create backup scenarios – perhaps your RAM disk driver supports periodical backups to physical disks. So you loose just recent changes. Or you can use other backup software that does backups for you. Backup shouldn’t interfere too much since building is done entirely on RAM disk. Or, if you want to be on the safe side, use RAM disk for output only. And don’t forget using source safe which is always a necessity regardless of the underlying disk type. - you have to allocate RAM
You loose working RAM. This might be not that bad as it sounds. First, RAM is cheap and running on 4GB (usually only ~3.5GB or less are available due to PC architecture) machine is not uncommon. Next, RAM disks might use OS dedicated RAM AFAIK. (You know, in 32 bit Microsoft OS is RAM usually divided like 2GB to applications and 2GB to OS). And if RAM is still an issues then one might consider switching to a 64bit OS where RAM size is not limited to 4GB.
RAM disks are an risky extreme solution. On the one hand they boost I/O to the sky while on the other hand your data is volatile. However, understanding the risks and taking proper precautions this scenario is very feasible, at least for me. I am all for using RAM disk for my entire solution.
And here is my RAM disk pick: RAMDisk from QSoft (supports all flavors of Windows, both 32 and 64bit, periodical backup, excluding RAM ranges, etc.). It is my first pick and I am very careful right now. I’ll see how it goes and if I don’t have problems with it I will stick with it. Ah, it is also dirty cheap. And my build times are down to the ground, VS looks lightning fast.
Nice post, I have tried RAMdisk based on your recommendation and I like it quite a bit!
Interesting!
How do you deal with source control management?
We use Perforce, which sets up a local “depot” which needs to be mapped to a local drive/path. It sounds like with a product like “RAMDisk” you would need to have the source tree on your RAM drive and have your source control management set to the RAM drive path?
Thanks for the tip!
Hi Dan,
I am not familiar with Perforce, but I do understand your problem. I am using TFS which doesn’t work like that and thus I don’t have such problems. Actually, there is one hackish thing you might try: use NTFS reparse points (i.e.: http://www.hanselman.com/blog/MoreOnVistaReparsePoints.aspx)