Visual Studio lento numa partilha VPN: porque guardar se torna idas e voltas

Uma solução que abre num segundo a partir de um disco local leva trinta segundos a abrir a partir de uma partilha alcançada por um túnel. O túnel raramente é a causa por si só. O que muda é que operações que eram chamadas locais passam a ser idas e voltas síncronas, e o editor executa várias delas antes de a janela aparecer. O mecanismo abaixo explica porque é que cada uma é cara e quais pode remover.

O que o editor faz enquanto um ficheiro está aberto

Um editor com seguimento de alterações mantém uma subscrição em cada ficheiro aberto. Um volume local serve essa subscrição a partir do sistema de ficheiros sem rede. Através de uma partilha a mesma funcionalidade pode degradar-se em leituras repetidas de metadados, porque o modelo de notificações não se comporta da mesma forma sobre SMB. Desativar o seguimento de alterações é uma primeira experiência justa, pois remove uma classe inteira de pedidos sem tocar no túnel.

O sistema de projetos acrescenta tráfego próprio. Carregar uma solução enumera diretórios, lê ficheiros de projeto e pode sondar SDK ou pacotes, e cada sondagem é uma ida e volta quando o caminho é remoto. Uma solução com muitos projetos multiplica essa contagem, e por isso o tempo de abertura cresce mais depressa do que os tamanhos dos ficheiros sugeririam.

Consultas da shell que expiram antes de o menu aparecer

O Windows contribui com uma segunda fonte de bloqueios que nada tem a ver com o IDE. O Explorador e as suas extensões de shell voltam a resolver impressoras, unidades mapeadas e atalhos usados antes, sempre que um menu de contexto abre. Quando esses destinos estão numa rede que o túnel não alcança, cada resolução bloqueia até expirar um tempo limite, e só então o menu é desenhado. É por isso que um clique direito pode ficar pendurado segundos enquanto o ficheiro se abre normalmente.

Remova os mapeamentos mortos e as filas de impressão, ou mantenha apenas os que existem na rede em que está realmente. O mesmo raciocínio cobre tudo o que resolve um caminho em segundo plano, incluindo listas de ficheiros recentes e pastas afixadas.

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

Porque ganha uma cópia de trabalho local

Trabalhar diretamente na partilha é a pior configuração para um ciclo de edição, compilação e teste, porque o editor, o compilador e o cliente de controlo de versões leem cada um esses ficheiros remotos em separado. Cada um paga a sua própria ida e volta, e uma compilação paga uma vez por ficheiro. Uma cópia local com envios através do repositório substitui uma enxurrada de pequenas travessias por uma única intencional. A ligação não melhorou; o número de travessias colapsou.

Isso é uma mudança estrutural e não um exercício de afinação, e é exatamente por isso que funciona quando as definições do túnel não funcionam. Também torna o modo de falha óbvio: se a compilação continua lenta com uma cópia local, a partilha nunca foi o problema.

Mova o histórico como um único objeto

Quando o próprio repositório tem de atravessar o túnel, envie o histórico num único objeto em vez de o percorrer. Um pacote é um único ficheiro e, portanto, uma única transferência, enquanto um checkout que percorre milhares de objetos soltos custa milhares de travessias. O Mercurial e o Git suportam ambos essa forma.

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

A revisão base é a parte que é preciso acertar, porque decide quanto histórico viaja. Empacotar tudo funciona e desperdiça a ligação, enquanto empacotar desde a última alteração comum move apenas o que falta ao outro lado.

Meça três operações antes de culpar a largura de banda

Meça três coisas em separado: um ficheiro pequeno aberto, um diretório listado, um guardar concluído. Se os três forem lentos em proporção ao número de ficheiros, o custo são idas e voltas. Se um encravar enquanto os outros estão bem, suspeite de um tempo limite contra um recurso inalcançável e não da largura de banda. Anote em que rede estava a máquina em cada execução, porque um portátil que se reconecta a outro perfil pode mudar a resposta entre tentativas.

Depois repita as mesmas três contra uma cópia local do projeto. A diferença é o preço da partilha, e é esse o número a citar quando alguém propõe uma ligação mais rápida como solução.