Now that Visual Studio 2010 has shipped, people are asking about preferred hardware configurations.  Customers want to know how to take advantage of all the cool new features that we have packed into this release.  We have published minimum hardware and software requirements, of course. You can install and run Visual Studio 2010 on almost any machine running 32-bit or 64-bit versions of Windows XP, Vista, or Windows 7 with at least 1 GB of RAM. (We recommend at least 2 GB of RAM on a 64-bit flavor of the OS.) You can install on any release of Windows Server 2003 or 2008, and install on a virtual machine running any of the supported configurations.  In fact, as I travel around and talk about this release, I usually take my teeny little Netbook with me and talk about the fact that I have VS 2010, TFS 2010 and a build server all running on it and it’s a very usable (though admittedly, not speedy) development environment. If you spend a good portion of your day inside Visual Studio developing and testing software, you might not be satisfied with the minimum hardware configuration. You probably want to know how to make your VS development experience lightning fast.  We realize that not everyone needs it or can afford it, but we have built Visual Studio 2010 so that it can take advantage of powerful hardware when it is available. First let me describe what I consider to be a Developer’s dream machine for Visual Studio 2010. The hardware I would recommend is the following:

• a multi-core processor with 4 GB of RAM and a fast hard drive
• the 64-bit version of Windows 7
• a graphics card with multi-Monitor support
• two (or more) high-resolution video displays

Whether it would be worthwhile for you to invest in hardware with these capabilities depends on how you intend to use the product on a regular basis. Some configuration choices are obvious no-brainers. If you are targeting 64-bit applications, you are going to need to install Visual Studio on a machine with a 64-bit version of the OS installed.  If you want to make sure your multi-threaded application behaves correctly, you need to develop and test it on a multi-core processor – and, in my experience, it takes at least 4 cores to adequately test and uncover the hard to find race conditions that can creep into your code.  If you care about Visual Studio responsiveness, you will want a fast hard drive and enough RAM so that you not driving additional paging activity to the disk. Beyond those generalities, though, let me discuss some common usage scenarios and how they might influence the machine configuration you use to run Visual Studio to the max.

Graphics card & multiple monitors

Personally, the premium hardware option I would give the most consideration to is your video display technology. I find that larger video displays significantly improve developer productivity.  They allow you to see much more of your code, project design and markup at any one time.  The WPF-based shell in Visual Studio requires a video card capable of running Direct-X 9 and supports a display with a minimum resolution of 1024 x 768.  But that is just to get started.  You will find WPF performance is much improved under Direct-X 10, which requires Windows Vista or later. If your video card can support multiple monitors, Visual Studio 2010 lets you take full advantage of them.  You can undock any window open in the IDE and re-position it anywhere across your video display surface, as described in this “Quick Hit” training video.  You can display your code on one monitor and be looking at debug windows in a 2^nd monitor, for example. So, think about maximizing the screen real estate available for Visual Studio 2010 to use & plan accordingly.  For instance, Windows 7 has improved multi-monitor support, including Snap for automatically positioning and sizing desktop windows.  One final consideration is that multiple monitor support currently won’t work at all on a virtual machine.  If that isn’t a showstopper & you still want to run Visual Studio 2010 on a Hyper-V guest machine, we recommend you configure some additional extra RAM.  Use 1.5 GB instead of the minimum 1 GB, for example.  The extra memory helps with the performance of software-based rendering of our WPF content, as well as helping with virtualized disk IO.

Multiple processor cores

Customers running portable or desktop machines that contain multiple processors will benefit from targeted improvements in Visual Studio performance.  While it remains true that many interactions with the IDE continue to be single-threaded, we have introduced multi-threading in a number of key places.  Find in Files, for example, is a potentially long-running command that is now multi-threaded and does not block the UI.  Similarly, some of the long running database, architecture and TFS tools are now multi-threaded.  In addition, WPF rendering is performed on a separate thread.  If you are compiling native programs & Build performance is important, you can do native Builds in parallel. This is actually not a new feature; it has been available since VS 2008. Read more about the /MP option to Build using multiple processes here. There are several other scenarios worth mentioning where multi-core machines are attractive.  Since I usually have more apps than Visual Studio active on my desktop at the same time, additional processors available on my workstation helps to keep my other desktop applications responsive, even when Visual Studio is in the middle of a long running Build operation.  Of course, if you are doing any concurrent programming yourself to try to exploit the hardware trend toward more cores, you will definitely want to debug and test your application on a multi-core machine.  This will also give you a chance to try out some of the great new tools for parallel programming that ship in Visual Studio 2010 and the .NET Framework 4.0.

Virtual memory

In a previous blog entry, I described some of our efforts to improve virtual memory usage in Visual Studio 2010.  The basic problem is that the main Visual Studio process, devenv.exe, is a 32-bit process, which means it encounters an architectural constraint that limits the private address to a maximum of 2 GB on a 32-bit version of the OS.  Moreover, as a practical matter, it is never possible to commit virtual memory up to the 2 GB architectural limit.  Due to fragmentation, for instance, out-of-memory errors tend to occur significantly earlier. As I discussed previously, our biggest virtual memory tuning effort for Visual Studio 2010 was directed at making sure that Visual Studio’s virtual memory usage never went higher than 1.5 GB for the duration of an extended test scenario that we ran against six large-scale customer applications.  We chose the 1.5 GB ceiling on virtual memory usage conservatively.  At that level, Visual Studio would be quite stable & would run without any serious risk of encountering out-of-memory errors.  The 1.5 GB ceiling on virtual memory usage also provides enough headroom for customers that also want to run popular 3^rd party extensions. The results of our virtual memory tuning were positive; by the time we released VS 2010 to manufacturing, all these scenarios comfortably ran below the 1.5 GB target.  Nevertheless, while Visual Studio remains a 32-bit process, you can still load enough different components into Visual Studio and get yourself into trouble. Once the devenv.exe 32-bit private address space is exhausted, Visual Studio will crash. If you encounter that kind of instability when you are running Visual Studio, the easiest workaround is to install a 64-bit version of the OS on the machine where you run Visual Studio.  On a 64-bit OS, Visual Studio can address up to 4 GB of private address space, doubling the amount of virtual memory available to Visual Studio 2010.  Just to be clear, this is true on any 64-bit version of the Windows or Windows Server OS. So, the guidance is if you are planning on configuring Visual Studio to the max and also need to support large projects and solutions, you are probably a good candidate for installing Visual Studio on a 64-bit OS. Here’s some additional comments from Mark (who helped write this post :)) – http://blogs.msdn.com/ddperf/archive/2010/04/29/your-visual-studio-2010-dream-machine.aspx Have fun with your “Dream Machine!”

Brian