Visual Studio Slow on a VPN Share: Why Saves Become Round Trips

A solution that opens in a second from a local disk takes thirty seconds to open from a share reached through a tunnel. The tunnel is rarely the cause by itself. What changes is that operations which were local calls become synchronous round trips, and the editor performs several of them before the window appears. The mechanism below explains why each one is expensive and which ones you can remove.

What the editor does while a file is open

An editor with change tracking keeps a subscription on every file it has open. A local volume serves that subscription from the filesystem with no network involved. Across a share the same feature can degrade into repeated metadata reads, because the notification model does not behave the same way over SMB. Turning change tracking off is a fair first experiment, since it removes a whole class of request without touching the tunnel.

The project system adds traffic of its own. Loading a solution enumerates directories, reads project files and may probe for SDKs or packages, and every probe is a round trip when the path is remote. A solution with many projects multiplies that count, which is why open time grows faster than the file sizes would suggest.

Shell lookups that expire before the menu appears

Windows contributes a second source of stalls that has nothing to do with the IDE. Explorer and its shell extensions re-resolve printers, mapped drives and shortcuts that were used before, every time a context menu opens. When those targets sit on a network the tunnel cannot reach, each resolution blocks until a timeout expires, and only then does the menu paint. That is why a right-click can hang for seconds while the file itself opens normally.

Drop the dead mappings and printer queues, or keep only those that exist on the network you are actually on. The same reasoning covers anything that resolves a path in the background, including recent-file lists and pinned folders.

net use
Get-Printer | Select-Object Name, PortName
Measure-Command { Get-ChildItem \files\proj | Out-Null }

Why a local working copy wins

Working directly on the share is the worst setup for an edit-build-test loop, since the editor, compiler and version-control client each read those remote files separately. Every one of them pays its own round trip, and a build pays once per file. A local copy with pushes through the repository replaces a flood of tiny crossings with a single intentional one. The link has not improved; the number of crossings has collapsed.

That is a structural change rather than a tuning exercise, which is exactly why it works when tunnel settings do not. It also makes the failure mode obvious: if the build is still slow with a local copy, the share was never the problem.

Move history as one object

When the repository itself must cross the tunnel, send history in a single object instead of walking it. A bundle is a single file and therefore a single transfer, whereas a checkout walking thousands of loose objects costs thousands of crossings. Mercurial and Git both support that shape.

hg bundle --base 9f2c1a7e outgoing.hg
hg unbundle outgoing.hg
git bundle create repo.bundle main
git clone repo.bundle repo

The base revision is the part to get right, because it decides how much history travels. Bundling everything works and wastes the link, while bundling from the last common changeset moves only what the other side lacks.

Time three operations before blaming bandwidth

Measure three things apart: one small file opened, one directory listed, one save completed. If all three are slow in proportion to file count, the cost is round trips. If one stalls while the others are fine, suspect a timeout against an unreachable resource rather than bandwidth. Note which network the machine was on for each run, since a laptop that reconnects to another profile can change the answer between attempts.

Then repeat the same three against a local copy of the project. The difference is the price of the share, and it is the number to quote when somebody proposes a faster link as the fix.