Do you have performance problems when you work on Visual Studio projects via a network share?

Question

We have tremendous problems with Visual Studio (2008, if that matters) locking up and slowing down when accessing projects over a network drive. It can take several minutes to open a large Web site project through a mapped drive, and saving even a single file can take a minute or more.

I fired up Wireshark and watched the traffic. VS, it seems, requests massive amounts of files from the network -- there's an enormous amount of SMB traffic. I've done some research, and this traffic seems to stem from two situations.

1. VS has to have everything in its own process to provide Intellisense.
2. VS needs to have all the source in order to compile the project.

All the advice I've read seems to boil down to the same thing: work locally, not on a remote machine, then push your code to an integration server via source control.

This would sure solve our problems (VS is quite fast working locally), but what if you can't work locally? What if the project and the infrastructure required to run it is too large and complicated to be replicated on everyone's individual machines?

We've gone 'round this problem a couple times, and the only way we can figure to work on these projects is direct access via a mapped drive. However, the VS slowness and lockups are really becoming a problem.

One solution: we installed VS on the server and work on the projects directly on the servers via RDP. Seriously.

So, I ask:

What does everyone else do? Do you work via the network, or do you replicate projects locally? If remotely, do you suffer from VS performance issues.

Answer 1

We work locally and use SVN to keep all our code on the server.

I find VS 2008 quite slow working locally sometimes so I wouldn't fancy working on a network share.

Answer 2

I encountered similar problems everytime I worked (work = anything else then just copy / paste files) over a network drive. The problem occured with ZendStudio and Eclipse.

Why not use any kind of source control?

Answer 3

When working on Windows based projects I've always worked locally.

Once at a unix shop (AIX iirc) developers would work via NFS mount and checkin/checkout via RCS...

Answer 4

I'm not terribly surprised that using VS to load projects over a network share has performance issues. VS (in any language) is constantly getting information from files in the project. Once you start loading this over a network you're at the mercy of the underlying network connection. All lags and access issues will directly translate into VS having an issue loading file contents.

I would advise copying the solution locally and using some form of source code control to sync the project on the share.

Answer 5

Trying to compile over a network share is horribly slow using visual studio. Your start times will be bad as the intellisense database is regenerated. Each compilation has to go over the network multiple times. Linking takes forever.

If you need the output of your compilation on the network, I'd recommend doing your compile locally and defining a post-build command to copy the results to your share.

If, as you say, you cannot pull everything locally then I'd suggest your project is too big and needs to be broken up into more manageable chunks. For a multi-tier application, break it up by tier and invest in some form of continuous integration (e.g. CruiseControl) to automatically build individual pieces. In this way you can work locally on an particular piece and pull the pre-build portions from CI for the other pieces of the application.

Answer 6

I'm using VS2005 across to a network share and not having any performance issues. However, it is a new server (Windows Server 2008). I don't have any other data points for VS since using it at work is relatively new for me.

However, some datapoints from using Netbeans for previous projects on a network share... Local build time for my project was 2 minutes on Vista, on a fast dual-core AMD 64-bit machine. For a network share project, on a Server 2003 box, it was 20 minutes. Building that same project from an ancient Tablet PC (1ghz, single core) running XP locally was around 5 minutes. Interestingly enough, the Tablet PC could build on the Server 2003 box in the same 5 minutes.

For those asking "why" on the network share. The network share is automatically backed up, archived, etc. Also, that way I can very easily look at the same projects from multiple machines without having to worry about pushing back into the repository, etc. Once you've gone to having your dev stuff on a device where you can get to it from anywhere/anything, you'll never want to do local storage again!

Answer 7

I am using my code locally, I am having 48 projects(VC++ and C++ combination), in my solution. I am using VSS to control code. But I am still facing preformance issues. How you got solved your problems. May be yours is Web based technologies, and mine is VC++ I think we need to do some thing to solve this performance issues. I am not getting proper solution for this. Earlier I was having 512 ram, now i got 1GB ram. but still problem not solved. I tried to open only three projects (made it as seperate solution) which are necessory out of 48 in same solution. But still problem not solved. :( How to solve this?

Answer 8

I have performance problems via network anything, they just aren't good enough yet.

Answer 9

I thought it was common knowledge that disk-speed is one of the major "slowness" factors when it comes to using VS in Windows. Most dev machines I've built have had projects located on 10k RPM RAID0 drives, or at least a single 10k RPM drive. And even then it seems slow sometimes. Just the way it is, I suppose, until VS2009/VS2010 fixes it? :)

Answer 10

If the code is too complicated to install on everyone's machine, then don't put it on everyone's machine. Does everyone need to have everything in order to do productive work?

Answer 11

This is happening to me also.

Out of interest, to the people it is happening to - is the central server Windows Server 2003 based?

I have a friend running Windows Server 2008 and he doesnt have a problem. I used Windows Server 2003, and I do receive slowness opening and saving projects/files.

Could a difference in the netwokring be the difference?

Answer 12

I have 79 projects in my solution that I work with. Several hundred thousand lines of code. I pull my source down everyday from TFS and build it; it's a lot of code, but it's a far better solution than trying to work over a network share.

Answer 13

~~UPDATE~~

Ok, so I did some playing around today.

Are the people who are experiencing slow file saving running Windows 7?

It seems on my network of computers, they are all slow to open projects over a network. However once the project is open, opening a file and general VS use is OK.

The difference is when saving a file in Vista it is instant, in Windows 7 there is a lagg of a few seconds.

So... are the people experiancing slow file saves running Windows 7?

Answer 14

From my experience, this lag when working on a network share is 99% due to Intellisense. Disable it and you'll see.

Answer 15

Its not intellisense otherwise why would it be ok on Vista but not in Windows 7?

Also disabling intellisense isnt exactly a solution for this. Intellisense makes VS, other wise its just a text highlighter :)

Answer 16

A more legitimate situation of having the source code on a share is when one has a non-Windows host on which a (number of) virtual Windows machine is running.

I have this exact situation where my desktop machine (the host) is running Debian and I use VMware to run various virtual Windows machines (the guests), including one that has Visual Studio installed so that I can target Windows OS's. Having the source code on a Samba share on the host machine has the following pro's:

• The source is not duplicated, so there is no way to confuse different copies while working on several virtual machines at the same time.
• I have full control over the source from my preferred OS.
• I can turn on and off any of the virtual machines, or roll back to a snapshot, without the risk of loosing changes.
• I can build (etc.) from the same source on several machines without having to commit changes before the source fully tested (reason: I have to use Subversion <1.5).

The only problem with this setup is that Visual Studio (6,7,8,9) is painfully slow.

I have mounted the partition (on which the share lies) with "relatime" and this works in as far as the disk activity on the share moderate, but Visual Studio keeps the (virtual) network card occupied all the time.

Any solutions to this would be very appreciated.

Answer 17

disabling Intellisense indeed speeds up saving and opening files trough a UNC share dramatically

http://blogs.msdn.com/saraford/archive/2007/12/03/did-you-know-how-to-turn-off-intellisense-by-default.aspx

but then again, as stated in other comments, you might as well use a good text editor