Should I store my code/projects on my SSD or my secondary drive?

Question

I just got a new box.

It has an SSD for the primary drive and a 1TB SATA hard disk for the secondary drive.

I'm going to run Windows OS and my binaries on the SSD
and keep all my downloads/documents/music/etc on the secondary drive.

My question is, should I also keep my Visual Studio Projects and code on the SSD, or keep them on the secondary drive?

The faster SSD would presumably be better for compiling and indexed searches, but would it be better to keep it on the 2nd drive for a more parallel disk IO situation?

Solution 1

SSD have a much better IO and therefore it makes sense to have your code on the SSD disk.

Solution 2

It depends on the drive you have. The read is will always lose to the SSD, but maybe not on the write performance. Write performance is going to be important during compilations for creating new executables, assemblies and other build artifacts.

Copy one of your larger solutions to the HD and the SSD and compile both. You'll notice the difference one way or the other and have your decision. My guess is the HD will be faster for compiles/builds but the ssd will win everythig else.

Solution 3

I don't know if this is possible in Visual Studio, but the best may be a combination of the two. Put the source code on the SSD, but have the compiled objects written to the HD. This is how we have out make based projects layed out, but for other reasons.

Solution 4

Hard drive speed is important to overall Visual Studio performance. Scott Guthrie touches on it well in this post:

Multi-core CPUs on machines have gotten fast enough over the past few years that in most common application scenarios you don't usually end up blocking on available processor capacity in your machine.

When you are doing development with Visual Studio you end up reading/writing a lot of files, and spend a large amount of time doing disk I/O activity. Large projects and solutions might have hundreds (or thousands) of source files (including images, css, pages, user controls, etc). When you open a project Visual Studio needs to read and parse all source files in it so as to provide intellisense. When you are enlisted in source control and check out a file you are updating files and timestamps on disk. When you do a compilation of a solution, Visual Studio will check for updated assemblies from multiple disk path locations, write out multiple new assemblies to disk when the compilation is done, as well as persist .pdb debugger symbol files on disk with them (all as separate file save operations). When you attach a debugger to a process (the default behavior when you press F5 to run an application), Visual Studio then needs to search and load the debugger symbols of all assemblies and DLLs for the application so as to setup breakpoints.

Visual Studio Blog recommends using a SSD:

Hard drive type matters! And here is another trick to make solution load even faster. Visual Studio telemetry shows that machines with an SSD storage load solutions 2-3 times faster than a regular hard drive. As such, we strongly recommend considering an upgrade to SSD if you are using a regular hard drive. While ideally Windows, Visual Studio, and your solution would all be contained on an SSD for the maximum impact, having Windows installed on SSD will have a huge impact on your solution load.

View more solutions

Comments

[fr0man]

I know it has better IO, but all the OS and Binaries will be reading from the SSD. I'm not sure if it mightn't be better to let the code files get read in from the secondary in a parallel fashion.

[Dan Rosenstark]

@fr0man, doubt it, Christian's simple answer is probably right. It's MUCH faster, so that goes beyond all other concerns.

[alord1689]

This sounds complicated. Is there a root setting for the target output directory or do you have to modify the bin setting it for each project in the build configuration?