Visual Studio 2010 Hardware Requirements

re: Visual Studio 2010 Hardware Requirements

Miha Markic — Wed, 24 Dec 2008 18:03:57 GMT

I am thinking about using SSD(or SAS or Velociraptor) most probably in RAID1 for sources and/or RAM disk for object files.

Do you have any performance tests for such configurations?

re: Visual Studio 2010 Hardware Requirements

David Berg — Wed, 24 Dec 2008 19:59:54 GMT

Miha,

We used to test with 10,000 RPM HDs (like the Velociraptor) but quit because it wasn't a "typical user experience" (but it did help the throughput in our test lab). We do most of our testing on 7,200 RPM HDs on the basis that it's a fairly standard configuration that sits in the middle of what most of our customers have. We don't currently test SSD in DevDiv (although Windows does).

In general, you can expect that a faster drive will improve performance in any disk bound scenario. The biggest advantage of SSD drives is that you eliminate seek time, making them ideal for applications with high random I/O.

The only problem with putting object files in a RAM disk is when the RAM comes from system memory it effectively reduces the amount of memory available for disk caching. So you gain in some areas, but may lose in others.

You might want to turn off search and virus checking for the directories/drives where you put your object files (if you haven't already). We do most of our performance testing with search and virus checking off, otherwise the results are too noisy.

Regards,

Dave

re: Visual Studio 2010 Hardware Requirements

Josh — Wed, 31 Dec 2008 06:42:09 GMT

"That said, there’s very little benefit to making a text editor 64 bit "

So VS2010 is *just* a text editor? It kinda does a bit more than that, stuff I'd imagine would be useful under 64-bit. I'd like more details on the pros/cons that you guys ran into.

re: Visual Studio 2010 Hardware Requirements

David Berg — Wed, 31 Dec 2008 09:00:08 GMT

Josh,

The pro of 64 bits is access to more than 4GB of memory (which can help some apps trememndously). The con is increased pointer size, which increases data sizes, in term consuming more memory, which take a little longer to manipulate. (There's also a hit to debugging performance due to differences in how stack frames are built.)

Yes, VS is much more than a text editor. The real question is which parts of VS would benefit from being able to access more than 4GB of memory? Text editing probably not. Even if you had more than 4GB of source code, annotations, and cross references - would we really benefit from having it all in memory? It's unlikely that a single user would ever reference that much source material. What's more important is a good on disk index structure that allows us to rapidly retrieve information as necessary, and cache it where it makes sense. By avoiding 64 bits we keep data structures smaller, so we actually can keep more in memory with a smaller footprint, and access it faster than if we went to 64 bit.

Now, where we have parts of VS that do benefit greatly from accessing more than 64 bits, then it would make a lot of sense to make those parts of VS 64 bits. Also, some parts of VS have to be 64 bits in order to support 64 bit code development.

So, as I said, if you're doing 64 bit development (and the only real reason to do so is if you're writing apps that need more than 4GB), then you will absolutely want a 64 bit system, and probably want more than 4GB of RAM. Or if you're using VS in some kind of application server environment, where it's accessible to multiple users, then you may also want more than 4GB of memory.

But for the average developer, writing 32 bit apps, then 4GB should be plenty (at least for VS2010).

Regards,

Dave

re: Visual Studio 2010 Hardware Requirements

Olaf van der Spek — Wed, 11 Feb 2009 23:50:57 GMT

> If you’re going to do multi-threaded programming,

Can VC already compile multiple files of a single project in parallel? With 4/8 cores/threads being easily available, I certainly hope so.

re: Visual Studio 2010 Hardware Requirements

David Berg — Thu, 12 Feb 2009 00:28:27 GMT

MS Build 3.5 (NETFX3.5/VS2008) supports a parallel build from the command line (http://msdn.microsoft.com/en-us/library/bb651793.aspx).

The VC IDE also supports a parallel build, but it's only VC, not the rest of VS2008 (http://blogs.msdn.com/saraford/archive/2008/09/30/did-you-know-only-vc-supports-parallel-building-within-the-ide-324.aspx).

re: Visual Studio 2010 Hardware Requirements

David Berg — Thu, 12 Feb 2009 17:13:54 GMT

On the subject of build performance, here's a recent post by Jim Lamb on improving TFS Build performance, note that a lot of the suggestions apply to any build system.

http://blogs.msdn.com/jimlamb/archive/2009/02/10/improving-build-performance-in-tfs-2008.aspx

re: Visual Studio 2010 Hardware Requirements

Ketan — Tue, 17 Feb 2009 07:50:31 GMT

I would suggest to focus on general performance and basic tools (like C++ Refactoring tools, Code snippet support etc.) instead of using WPF, which does not add any value to code product! I am finding myself going back to some other editor which does the one job well without eating away my resources!

Some how, I find your Goal #1 and #3 contradictory.

re: Visual Studio 2010 Hardware Requirements

David Berg — Tue, 17 Feb 2009 08:40:30 GMT

Ketan,

Yes, it's not uncommon for goals to be somewhat contradictory. Striking a good balance is always the challenge. One of our biggest challenges with VS 2010 is making sure we make the right trade-offs.

WPF requires extra memory to load WPF, DX, and for DX buffers. Exactly how much depends on the GPU.

There are benefits to WPF, which include:

1) By leveraging the GPU WPF can offload processing from the CPU and free it up to do real work and let us create a more responsive UI.

2) WPF gives us better UI design / code separation.

3) WPF enables new features that would be cost prohibitive without the GPU.

However, Visual Studio is large and we won't be able to realize all the benefits in a single release. Hopefully though we'll be able to do enough that you will find it worth while.

re: Visual Studio 2010 Hardware Requirements

valued customer — Wed, 13 May 2009 21:42:11 GMT

My top three reasons for wanting a 64-bit devenv.exe:

1) Add-ins

2) Add-ins

3) Add-ins

Analysis add-ins such as Refactor, CodeRush, NDepend, Dotfuscator Pro, MemProfiler and the like eat quite a bit of memory, especially with a large solution. I have to resort to running some of these stand-alone (NDepend, Dotfuscator), losing a fair amount of integration with VS.

re: Visual Studio 2010 Hardware Requirements

Parashu — Fri, 26 Jun 2009 15:31:17 GMT

Hi Team,

this is Parshu, my system runnung with VS2008 and VS2005 and here i am facing the Performace issue. my system getting dead slow when i open both the Environments

this is my Sys configuration:

1.83Ghz CPU.

1GB RAM

160 GB HARDDISK

Please suggest me if i need to upgrade my sys Configuration.

Thanks in Advance

Parasu

re: Visual Studio 2010 Hardware Requirements

David Berg — Fri, 26 Jun 2009 17:36:59 GMT

Parashu,

The short answer is a qualified, yes - you should upgrade your hardware.

Here's why:

1) You didn't say anything about your OS or the size of your solutions. With only 1 GB of RAM - if your running XP, and if youre solutions are fairly small, then you may be okay where you're at. But, if you're running Vista or your solutions are large, then you're going to see some significant performance improvements from moving up to 4GB. And once you move to 4GB, if you're not running Vista, you're also missing out. With sufficient memory, Vista will do a better job of caching the hard disk than XP, so you'll see faster loads and fewer stalls.

2) I'm assuming from the CPU speed and memory that your system is at least a couple years old. As noted in point #2 in my original post, older systems tend to lack the cache and other micro-architectural advances of newer systems. So moving to a modern 2.x ghz system will probably result in a major speed up of anything that's CPU bound. Additionally, modern systems tend to have built in disk cache and better video systems.

3) You didn't say how many CPUs you have, so I'm assuming one. Almost everything I'm buying these days is dual or quad (and the rest is 8+ procs, I'm not buying any single proc machines - even most netbooks are hyperthreaded). VS isn't terribly multithreaded, but parts of it are. But at the same time, you said you're running VS2005 and VS2008 at the same time. Plus you're probably running other applications, and the OS has lots it wants to do. So you're probably missing the opportunity to parallelize work and improve responsiveness.

Finally, you asked about VS2005/2008, and I assumed above that was your primary focus. But the original post is about VS2010. VS2010 adds a lot of functionality and leverages WPF. You're going to want multiple CPUs, a good video subsystem, and lots of memory to leverage everything we're providing, especially if you're going to be running multiple copies or VS2005/VS2008 at the same time.

re: Visual Studio 2010 Hardware Requirements

Ramil — Wed, 22 Jul 2009 14:44:08 GMT

why Microsoft did not use ribbon UI in Visual Studio 2010

like Office 2007 and 2010

re: Visual Studio 2010 Hardware Requirements

David Berg — Wed, 22 Jul 2009 16:02:59 GMT

Changing to a Ribbon UI would require a substantial rework of the UI and it's not clear that Visual Studio would benefit as much as Office (I like it too). If you've got a lot of thoughts on why a ribbon UI would make you more productive, you might want to post them over on Jason Zander's blog or Soma's blog, as they're going to be much more involved in that decision than we will. (If you have thoughts on why a Ribbon UI would make VS faster, then by all means, post them here.)

Changing to a Ribbon UI would be pretty disruptive. Given that we're already replacing the editor, the shell, and completely reworking the multi-targeting system, I doubt that we could have handled a Ribbon UI in this release. While it might seem easy to rework the toolbars into a Ribbon UI while we're replacing the shell, it's not. That's because a lot of effort around the shell goes into making sure that the new shell has similar APIs and performance to the old shell, to minimize the disruption. Changing to a Ribbon UI would have substantially increased the disruption around changing to the new shell. It's really best to do those type of changes in stages.

re: Visual Studio 2010 Hardware Requirements

Ryan — Thu, 29 Oct 2009 20:51:21 GMT

I'm surprised at Microsoft.

I'm running a web server, lots of tools, services, and apps to help me develop programs. These are all in addition to all of the instances of Visual Studio that I may be running.

The above reccommendation "So the general rule of buying systems still applies – spring for as much memory as you can afford. It’s hard to have too much memory" is heartily heard. I have 4GB, on a (sigh) 32-bit operating system. So, I can only use roughly 3.2GB of it.

I have to constantly watch my memory usage to ensure that I'm not out (thrashing my HD by paging).

So, I've followed the recommendations by getting as much Memory as the 32-bit OS allows.

Now I'm waiting for a 64-bit version of Visual Studio so that I can move to a 64-bit OS?

I could move to a 64-bit OS now, but I have heard stories of a 50+% performance penalty running Visual Studio on such 64bit OSes.

How long am I going to have to develop on a 32-bit OS? Well, probably until Microsoft ports VS to 64-bit.

At some point I'll probably stop waiting an run a 32-bit OS on a Virtual PC (or on Windows 7's "Windows XP Mode"). Too bad VS is not written for the current OSes...

re: Visual Studio 2010 Hardware Requirements

David Berg — Thu, 29 Oct 2009 21:44:54 GMT

Ryan,

The 32 bit VS runs just fine on a 64 bit OS. I personally run 64 bit OSes at home and work. I don't see a 50%+ performance penalty. And if you do run VS on a 64 bit OS, you'll pick up an extra 2GB of VM (on a 32 bit OS VS gets 2gb of VM, on a 64 bit OS it gets 4GB).

You can go the virtualization route, but it's not necessary and will probably hurt your performance, so I wouldn't do it unless you have a really good reason.

Dave Berg