Visual Studio 2013 + TFS = Slow

Question

I am using a recently re-installed laptop with SSD. I am using Visual Studio 2013 with TFS.

My problem is that I need to wait for about 20 - 25 seconds when I\'m st

Answer 1

There are a number of options available to you which you haven't tried yet:

Local workspace vs Server Workspace

When you have a large workspace (meaning lots of files in your workspace) or when your workspace contains a lot of binary files (NuGet Packages for example), it may slow down considerably when it's configured as a "Local Workspace". Local workspaces keep the original file (latest version as your TFS server knows it) in a gzipped file on disk. Whenever a lot of files change, they're compared against the last known copy and based on that they're either checked in or checked out.

A Server workspace on the other hand simply looks at the 'read-only' bit of the files. If it has one, TFS will assume it's unchanged. If it doesn't have one, TFS assumes it's checked out.

Local workspaces have their advantages, especially if you work offline a lot, but they can cause serious slowdown in the cases described above.

Try configuring your workspace as a Server workspace to see if that removes the issue.

Visual Studio, by default, creates a Local workspace ever since this feature was introduced.

Remove large binary files, and scope the workspace appropriately

If you want to use a Local workspace, you may need to update your solution to ensure that NuGet packages are not checked in, large binary files in your workspace are cloaked and that you only grab the files you really need (e.g. create a new workspace for different branches).

To cloak a file, either edit your workspace mapping and add a folder you do not want to retrieve and set the action from "active" to "cloak", or you can cloak directly from the context menu of the Source Control Explorer, you can find it under Advanced then Cloak.

Instead of checking in your binary references, try to find corresponding NuGet packages, or create them yourself. Large binary files are always a pest when it comes to Version Control Systems, as you can never merge them and they basically just sit there.

Cache corruption

The Team Explorer client keeps a cache in the following location:

C:\Users{user name}\AppData\Local\Microsoft\Team Foundation{version}\Cache

Which may have become corrupted for some reason. Clearing all sub-folders and the VersionControl.config can be a last resort to get it working again.

Repair Visual Studio and turn off extensions

Sometimes Visual Studio itself can be a little confused by all the hotfixes, service packs and other things that get installed. To not even mention all the extensions that may influence it's behavior.

Some extensions can seriously slow down interactions with source control. The before mentioned Source Control Explorer Extensions, for example have an option to change the date of the files on disk, which can cause "Get" operations to stall at the very end for a number of seconds.

Turning off such extensions to see if the behavior still exists without them is always something you should do. Repairing Visual Studio and re-applying the latest update pack is also something that may resolve issues like these.

Suspect extensions include those that:

• Extend the Debugger
• Extend Team Explorer
• Extend the Source Control Explorer

Turn off Windows Proxy auto-detection

I've seen some strage behavior, not on all networks, not with all proxy servers, when Windows Proxy Auto Detection is turned on. Proxy detection can cause long waits as it's trying to figure out what proxy to connect to.

Try disabling the proxy script and auto-detection, if you're dependent on a proxy, try setting it directly in the classic proxy configuration screen:

Try to find the issue the hard way

Enable client side tracing as described here. In the devenv.exe.config include the following snippet. It will dump everything that happens around TFS to a log file. It can be a pain to pinpoint what's happening, but it will give you loads of information:

And you can run Visual Studio with Activity Trace Logging enabled. If there's a plugin misbehaving it often results in information in the ActivityLog.xml. To enable this type of traces, start visual studio with the /log option from the commandline. The log will be dropped here:

%AppData%\Microsoft\VisualStudio\12.0\ActivityLog.XML

In the worst case you can attach one Visual studio or a profiler (or the Intellitrace commandline tool) to Visual Studio and collect a log of everythign that happens inside Visual Studio.

And you could try monitoring your system with Process Explorer to see if IO or network access are slowing you down.