Building a fast Visual Studio machine
I want to build a PC to run Visual Studio very quickly. I have about 30 C# projects that include WCF services, IIS web services. So for me, quickly means fast edit, compile, run and debug cycles.
How should I balance my investment in CPU power, memory, and drive techology, when building a machine for my purposes?
Our dev team uses REALLY fast hardware... $6,000+ per Dev Machine as of January 2010.
The BIGGEST difference any one component made for us (we tested one thing at a time) was adding really fast I/O and putting all of our source code on that hardware. We went through about 10 different configurations (Various RAIDs with VRaptors, SSDs, Etc...) and the best item we came up with was the IOXtreme drive from Fusion IO.
http://www.fusionio.com/products/ioxtreme/
You'll need lots of RAM as the driver "locks" RAM in larger quantities the smaller your formatted block size is on the drive.
Those bad boys are non-volatile, and SUPER fast at both Random reads and writes. For the money, we could not get our rigs to compile any faster.
I'll time a compile real quick to give you an idea...
OK, our Master solution with ALL code currently has 37 projects, and a total of 92,281 lines of "executable" code according to the Visual Studio Code Metrics Results. To compile it with DEFAULT C# developer settings in the IDE (just reloaded all settings so you can compare objectively with defaults if you want) takes 22 seconds. On an identical machine with 3 Velociraptors in RAID 5 takes 29 seconds, so about a 24% increase.
That test was run with CLEAN SOLUTION followed by REBUILD SOLUTION, so it should have been a full compile.
I don't know about all of you, but I compile frequently after small to medium changes. Probably on average 80-100 times per day. That means that JUST the IOXtreme drive is saving me 9.3 minutes per day. At $70 per hour (our average devs rate, roughly) that is $10 a day in time, per developer. So the thing takes about 90 days to pay for itself. Not bad really... they are free at this point.
Also, I REALLY strongly feel that compile times shoudl never be allowed to rise above a developer's threshold for distraction. Make me wait 2 minutes... In on Wiki or Google or Youtube wasting time. That is a lot harder to measure.
OK, so the whole rigs look something like this:
Windows 7 Professional 12GB RAM 2x Quad Core Xeons (E5504) @ 2.00 GHz. 8 GHz total per machine. Highpoint 2320 RAID Controllers Server Mobo (I forget the model, sorry) 3x Velociraptors in RAID 5, partioned into C, D, and E drives. Windows on C, programs on D, User Data folders on E. IO Xtreme Drive as Drive F. All code (ours and third party DLLs) is on Drive F.
Best of luck to you all!
There is a similar question here: Which PC components make the biggest impact on your compile times for Visual Studio.
The biggest bottleneck is going to be the disk drive when doing builds in Visual Studio. As of Visual Studio 2008, you can also take advantage of multiple processors or multiple cores during your builds. If it were me, I'd go with the following:
- Core I7 Platform
- 6+ GB RAM
- Windows 7 64-bit (it's faster than Vista)
- A fast solid state drive
- No active anti-virus software running during your build!
Further reading:
- Scott Gu's blog: Tip/Trick: Hard Drive Speed and Visual Studio Performance
- MSDN: Using Multiple Processors to Build Projects
- Adrian Kingsley-Hughes' blog on ZDNet: Windows 7 build 6956 performance test
- Scott Hanselman's blog: Faster Builds with MSBuild using Parallel Builds and Multicore CPUs
- Principled Technologies: Solid State Drives vs. Hard Disk Drives (pdf)
I use a ramdrive, from Dataram. Visual Studio doesn’t use all my PC cores (8 Core) so what I did was that I format the ramdrive with NTFS and activated Compression. Source coded has high compression ratio so a ramdrive of 2GB gives at least 4GB storage. You can also activate auto save of ramdrive! This method gives you the fastest IO, even faster than SSD. However you will notice that when the IO isn’t the bottleneck, VS is very poor in using multi cores.