SSD 驱动器和 Visual Studio IDE。大的改进? 真正的使用情况，没有理论

小开

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

小开

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.

小开

最佳答案

I've got hard data for Visual C# 2008. The short version is that you are best of spending your money on a faster CPU than faster I/O. Longer answer follows...

Our C# (.NET 3.5) solution contains 81 projects with over 2M lines of code (including comments and blank lines). A couple of years ago we upgraded from Pentium 4 3 GHz PCs with standard HDDs to Core 2 Duo 2.6 GHz PCs with 10,000 RPM WD Raptor HDDs (74 GB). The speedup was immense. About 10 minutes down to 3.5 minutes. All of this in in a Windows XP Pro 32-bit environment with 4 GB of RAM.

We also got one Gigabyte i-RAM (google it for information), which is basically a RAM hard disk with battery backup. Unlike an SSD which is fast for reading but slower for writing, the i-RAM is fast for both, but if you lose power then the battery only lasts for about 12 hours so you have to be disciplined with your check ins. This shaved another minute off the compile times on the Core 2 Dou platform (down to 2.5 minutes) compared to the 10,000 RPM Raptor HDD.

I've since discovered that those old 74 GB 10,000 RPM Raptor drives are slightly slower than your garden variety 7,200 RPM modern drive and we've proven that consistently benchmarking compiles. We haven't tried the new Velociraptors, but they would certainly be quicker but probably not enough to be worth it for compile times alone.

Last week we got a new Intel Core i7-870 platform with a G.Skill Falcon 128 GB SSD (with the Indilix Barefoot controller) and a standard 500 GB HDD as the second drive. I also chucked the i-RAM into this PC and tested all configurations.

Compared to the Core 2 Duo, which compiled in 3.5 minutes for HDD and 2.5 minutes for the i-RAM, the i7-870 compiles in 1 min 40 seconds for the SSD, HDD and i-RAM give or take 3 seconds.

So both times we've upgraded developer workstations, the vast majority of performance improvement in C# compile times has come from faster the CPU rather than faster disk. If you want to speed up compile times, put your money into the CPU rather than the disk.

That said, the SSD is much faster for loading Visual Studio and opening a solution (although I haven't got timings for that). If you can afford an SSD you'll never go back as every program on your PC loads so much faster it is incredible. But it won't significantly speed up your compiles. And that's with Visual Studio C# being single-threaded. If Microsoft ever got their act together and made their compiler in the IDE multi-threaded then we could actually use those four cores...

Update May 2012: We've now upgraded our PCs again and based on what we learned before we focused on CPU performance. The new PCs have Intel Core i7-2600k CPUs overclocked to 4.6 GHz, with Intel 510 Series 120 GB SATA III SSD, 16 GB RAM and a large CPU cooler! Surprisingly this nearly halved the compilation time, and I certainly put this down to the very large increase in CPU horsepower rather than the faster SSD.

C# compilation in Visual Studio 2010 performance results were:

159 seconds: Intel Core i7-870 stock (2.9 - 3.3 GHz), 4 GB RAM with SATA II SSD
109 seconds: Intel Core i7-2600k stock (3.4 - 3.8 GHz) 16 GB RAM with SATA III SSD
84 seconds: Intel Core i7-2600k overclocked (4.63 GHz) 16 GB RAM with SATA III SSD

小开

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!

小开

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.

小开

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

小开

I just upgraded a laptop to SSD by cloning the original 5400 RPM hard drive (surprisingly a painless process). I used a stopwatch to capture before and after metrics. (Dell Inspiron 1525, 3 GB of RAM, Windows Vista 32-bit)

Boot/Startup of Windows

63 seconds --> 52 seconds

Loading My ASP.NET Visual Studio Solution

In other words, the time from clicking on the .sln file to when Visual Studio is fully loaded and you can begin coding. I performed this once before taking measurements because the first time always takes longer than subsequent times.

16 seconds --> 8 seconds.

Debugging

F5 to the home page fully loaded.

5 seconds --> 3.5 seconds

小开

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.