Visual Studio lento nun recurso compartido por VPN: por que gardar se converte en viaxes de ida e volta

Unha solución que se abre nun segundo desde un disco local tarda trinta segundos en abrirse desde un recurso compartido ao que se chega por un túnel. O túnel raramente é a causa por si só. O que cambia é que as operacións que eran chamadas locais convértense en viaxes de ida e volta sincronizadas, e o editor realiza varias antes de que apareza a xanela. O mecanismo seguinte explica por que cada unha é cara e cales pode eliminar.

Que fai o editor mentres un ficheiro está aberto

Un editor con seguimento de cambios mantén unha subscrición en cada ficheiro aberto. Un volume local serve esa subscrición desde o sistema de ficheiros sen rede. A través dun recurso compartido a mesma función pode degradarse en lecturas repetidas de metadatos, porque o modelo de notificacións non se comporta igual sobre SMB. Desactivar o seguimento de cambios é un primeiro experimento xusto, xa que elimina toda unha clase de peticións sen tocar o túnel.

O sistema de proxectos engade tráfico propio. Ao cargar unha solución enuméranse directorios, lese ficheiros de proxecto e pode sondar SDK ou paquetes, e cada sonda é unha viaxe de ida e volta cando a ruta é remota. Unha solución con moitos proxectos multiplica esa conta, por iso o tempo de apertura medra máis rápido do que suxerirían os tamaños dos ficheiros.

Buscas do shell que caducan antes de que apareza o menú

Windows achega unha segunda fonte de bloqueos que nada ten que ver co IDE. O Explorador e as súas extensións de shell volven resolver impresoras, unidades asignadas e atallos usados antes cada vez que se abre un menú contextual. Cando eses destinos están nunha rede á que o túnel non chega, cada resolución bloquéase ata que vence un tempo de espera, e só entón se pinta o menú. Por iso un clic dereito pode colgarse segundos mentres o ficheiro se abre con normalidade.

Elimina as asignacións mortas e as colas de impresión, ou conserva só as que existen na rede na que estás realmente. O mesmo razoamento cobre todo o que resolve unha ruta en segundo plano, incluídas as listas de ficheiros recentes e os cartafoles fixados.

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

Por que gaña unha copia de traballo local

Traballar directamente no recurso compartido é a peor configuración para un ciclo de edición, compilación e proba, porque o editor, o compilador e o cliente de control de versións len cada un eses ficheiros remotos por separado. Cada un paga a súa propia viaxe, e unha compilación paga unha vez por ficheiro. Unha copia local con envíos a través do repositorio substitúe unha avalancha de pequenos cruzamentos por un só intencionado. A ligazón non mellorou; o número de cruzamentos derrubouse.

Iso é un cambio estrutural e non un exercicio de axuste, e é exactamente por iso que funciona cando os axustes do túnel non o fan. Tamén fai obvio o modo de fallo: se a compilación segue lenta cunha copia local, o recurso compartido nunca foi o problema.

Move o historial como un só obxecto

Cando o propio repositorio ten que cruzar o túnel, envía o historial nun só obxecto en lugar de percorrelo. Un paquete é un só ficheiro e polo tanto un só tránsito, mentres que un checkout que percorre miles de obxectos soltos custa miles de cruzamentos. Mercurial e Git admiten ambos esa forma.

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

A revisión base é a parte que hai que acertar, porque decide canto historial viaxa. Empaquetalo todo funciona e desperdicia a ligazón, mentres que empaquetar desde o último cambio común move só o que lle falta ao outro lado.

Mide tres operacións antes de culpar o ancho de banda

Mide tres cousas por separado: un ficheiro pequeno aberto, un directorio listado, un gardado completado. Se as tres son lentas en proporción ao número de ficheiros, o custo son as viaxes de ida e volta. Se unha se atasca mentres as outras van ben, sospeita dun tempo de espera contra un recurso inalcanzable e non do ancho de banda. Anota en que rede estaba a máquina en cada execución, porque un portátil que se reconecta a outro perfil pode cambiar a resposta entre intentos.

Logo repite as mesmas tres contra unha copia local do proxecto. A diferenza é o prezo do recurso compartido, e é o número que hai que citar cando alguén propón unha ligazón máis rápida como solución.