SSD drives and Visual Studio IDE. Big improvements? Real usage stories, no theory

Question

I want to go for Windows 7 + Intel SSD drives to speed up my Visual Studio 2008 development cycle.

The areas I want to speed up are:

• Compile/

Answer 1

I just bought one and the only regret I have is not buying an SSD any earlier.

Compilation times have been ok before already, but now the whole IDE is much more responsive. And it's not only Visual Studio, but also other applications. It's just so much easier to stay in flow when the whole system works this quickly.

Answer 2

I have also been considering this, and a while back I bought a quick SD card, that I can stick in the laptop and forget about it, so that Windows Vista can use the ReadyBoost feauture. That feels like it makes a difference, but it is certainly not enough to warrant buying an SSD drive just for that.

I then started running into problems when doing Subversion updates, and decided to scrap the ReadyBoost idea, and mount the SD drive on a mount point where I then created all my project files. The SD card is not very big (1 GB), but it has certainly reduced my wait time for builds and makes debugging a fair bit faster.

Most of this is subjective and I am answering a question that wants facts, with 'I feel this' and 'I feel that'. Because of my experimentation with running Visual Studio files from a different drive, I certainly believe it will make a difference, how much, and how much I am willing to pay for that is a question I am also keenly looking for a answer. My notebook can take another hard disk drive, and I have not been able to make up my mind between an SDD and a 7200 RPM laptop drive.

Answer 3

When I bought a new computer I was not sure what was the thing that made my experience faster.

However, a collegue of mine changed a 7200 RPM hard disk drive for an SSD. At once Visual Studio (especially starting/debugging ASP.NET) was at least two times as fast!

Answer 4

See Joel Spolsky's article Solid State Disks (2009-03-27).

Answer 5

After long performance tests I got the best setup here, but for a C++ compiler. You will need:

• SSD for Windows and Program Files (typically the C: drive)
• 1 TB WD Caviar Black in two partitions:
  • Drive D: A tiny one (max 35 GB) at the start cylinders having only a TEMP folder; You should map your TMP and TEMP environment variables to D:\TEMP (this one is really important!!!)
  • Drive E: with the rest of the drive storage; use this for general data storage, except for the software development stuff
• 1 TB WD Caviar Black in any partition layout you want to store your Visual Studio 2008 projects/solution. Based on Subversion usage I ended up with four partitions:
  • 820 GB for trunk and general purpose projects
  • 60 GB for a "feature branch"
  • 60 GB for a "stable branch" used during product stabilization
  • 60 GB for a "product quality branch" used for minor fixes on approved software
• 6-core or 8-core processor, using /MP compiler switch, (don't get confused with Visual Studio 2008 native "parallel project build" feature -- I don't know why the AMD Phenon II processor is working so good with this combination)
• Windows 7 64 bits (I'm not exactly sure why it runs faster in a 64-bit OS, even using a 32-bit compiler)
• SATA 3 compatible mainboard

This setup outperforms any other combination I've tested.

A typical compilation of a huge modular project will have the following results:

• Parallel build without /MP and regular HDDs: around 12:00 minutes
• This proposed setup: 4:30 minutes
• This setup, but using alternating to WD Caviar Green drives: +1:00 per drive (5:30 or 6:30 for both)
• Moving TEMP partition to a RAMDRIVE: 5:30

My conclusions are the following:

• Don't let TEMP folder run in SSD, since they are bad "writers" and don't have a comparable 64 MB cache inside WD Caviar Black
• Using a dedicated drive working as TEMP lets both WD drives work in parallel: the TEMP for cl.exe temp files and the project drive to store *.cpp/h, *.obj, *.lib, *.exe, etc.
• WD Caviar Black caching algorithms are impressive, combined with SATA 6 GB/s, outperforms a RAMDRIVE setup I've tested for the TEMP drive
• Partitioning reduces the impact on fragmentation which is inevitable in a compiler environment; the same is also valid for the TEMP drive

I hope I could help you.

Answer 6

As a test, we just ordered a 90 GB Sandforce based SSD to see if it could help our build times. We have a large, C++ project that takes 21 minutes to do a complete rebuild on (an older Xeon 3.4 GHz box.)

Running three tests on each, the time difference in builds was negligible; on the order of 30 seconds faster.

Our newer(!) Xeon 5150 box (with harddisk) rebuilds the same project in ~11 minutes, which goes to show that compiling really is CPU bound.

(This surprised me since I figured the awesome 4k and 512k read/write performance of an SSD would be super beneficial in builds.)