Het plaatsen van WSL2-projecten op je Windows-schijf verlaagt je prestaties—hier is waarom

Wanneer je voor het eerst begint met het gebruik van Windows Subsystem for Linux, lijkt alles te werken. Je kunt een repository klonen, afhankelijkheden installeren, je app uitvoeren en zelfs jezelf ervan overtuigen dat je nu 'Linux op Windows' hebt.

Dan voelt iets niet goed, en je merkt dat de opdrachten die direct zouden moeten zijn een merkbare hoeveelheid tijd kosten. Pakketinstallaties slepen, bestandswachters gedragen zich vreemd, en ontwikkelservers voelen traag aan op een manier die moeilijk aan een enkele oorzaak toe te schrijven is. In het begin wordt dit de schuld van WSL2 zelf gegeven, omdat dat de voor de hand liggende schuldige is, maar meestal is dat ook niet de juiste.

Het echte probleem is waar je bestanden zich bevinden

Het Windows-bestandssysteem introduceert een verborgen prestatievermindering

Als uw project zich ergens bevindt zoals:

/mnt/c/Users/YourName/projects/my-app

Je werkt niet echt op een Linux-bestandssysteem. Je werkt op het Windows-bestandssysteem, dat wordt benaderd via een vertaallaag.

Die detail is gemakkelijk te missen en verrassend duur. WSL2 draait een echte Linux-kernel binnen een lichte virtuele machine. Binnen die omgeving is er een native Linux-bestandssysteem. Het is snel, consistent en gedraagt zich precies zoals Linux-tools verwachten.

Echter, wanneer je toegang krijgt tot bestanden onder /mnt/c, /mnt/d of een andere aangekoppelde Windows-schijf, moet elke bestandshandeling een grens tussen Linux en Windows overschrijden. Die grens is waar de prestaties ten onder gaan (stilletjes, zonder fouten te geven, wat het erger maakt).

Waarom dit eigenlijk dingen vertraagt

Bestandsintensieve werkstromen versterken de bestandssysteemvertalingsoverhead

Moderne ontwikkelingswerkstromen zijn extreem bestand-intensief. Denk aan wat er gebeurt wanneer je iets uitvoert zoals:

npm install
pip install
cargo build
npm run dev

Deze tools maken duizenden kleine bestanden aan, lezen ze en wijzigen ze. Ze zijn afhankelijk van snelle toegang tot het bestandssysteem en voorspelbaar gedrag.

Op een native Linux-bestandssysteem is dit geoptimaliseerd, maar op het Windows-bestandssysteem dat via WSL2 wordt benaderd, omvat elk van die bewerkingen een vertaling tussen twee verschillende systemen.

Als gevolg daarvan werkt alles, maar alles is gewoon langzamer. Soms is het 2x langzamer, soms 10x langzamer, en in sommige gevallen kan het nog erger zijn. Je merkt het niet altijd meteen omdat de vertraging over veel kleine bewerkingen wordt verdeeld, maar na verloop van tijd telt het op.

Een van de gemakkelijkste manieren om dit probleem te observeren is met Git. Voer git status of git checkout uit op een grote repository die is opgeslagen onder /mnt/c, en vergelijk dit met dezelfde repository in je Linux-home-directory.

Het verschil is niet subtiel, aangezien Git veel bestandsysteemoperaties uitvoert. Het scant mappen, controleert metadata en vergelijkt bestandsstatussen. Op een trage bestandsysteembrug wordt dit pijnlijk duidelijk. Mensen geven vaak Git zelf de schuld of gaan ervan uit dat hun repository 'gewoon groot' is. In werkelijkheid doet de keuze van het besturingssysteem het grootste deel van de schade.

Een ander veelvoorkomend symptoom is onbetrouwbaar bestandsbewaken. Hulpmiddelen zoals webpack, Vite of nodemon zijn afhankelijk van bestandssysteemgebeurtenissen om wijzigingen te detecteren. Op een native Linux-bestandssysteem worden deze gebeurtenissen efficiënt geleverd.

Over de Windows-grens heen worden dingen inconsistent.

Je zou kunnen zien:

• Wijzigingen die geen herbouw activeren
• Vertraagde herladingen
• Toegenomen CPU-gebruik door polling-terugvallen

Dit is geen bug in je tooling, maar een gevolg van hoe bestandsysteemmeldingen worden vertaald tussen Windows en Linux. Verplaats het project naar het bestandssysteem van WSL2, en deze problemen verdwijnen meestal.

Het misleidende gemak van /mnt/c

Gemak verbergt de kosten van toegang tot verschillende systemen

Het is volledig begrijpelijk waarom mensen hier terechtkomen. Je begint in Windows en je bestanden en editor zijn daar. Het voelt natuurlijk om er gewoon toegang toe te hebben vanuit WSL2 via /mnt/c.

Dit geeft je de illusie van een uniforme omgeving. Eén bestandssysteem, toegankelijk vanaf zowel Windows als Linux, behalve dat het niet uniform is maar overbrugd, en bruggen hebben kosten.

Deze opstelling is prima voor incidentele bestands-toegang, maar het is niet geschikt voor actieve ontwikkelwerkbelastingen die afhankelijk zijn van frequent gebruik van het bestandssysteem.

Wanneer je werkt op een Linux-bestandssysteem binnen WSL2, is het verschil direct merkbaar. Je pad ziet er zo uit:

Nu werk je volledig binnen de Linux-omgeving en is er geen vertaallaag of overhead tussen besturingssystemen. Binnen deze directory, als je probeert afhankelijkheden te installeren, zul je merken dat ze sneller voltooid zijn, en ontwikkelservers starten ook sneller en herladen betrouwbaar.

Maar hoe zit het met toegang vanaf Windows?

Moderne editors ondersteunen al externe Linux-werkstromen

Dit is het deel dat mensen doet aarzelen. Als je project zich binnen WSL2 bevindt, hoe open je het dan in je Windows-editor?

Het antwoord is dat moderne hulpmiddelen dit al hebben opgelost. Als je VS Code gebruikt, stelt de Remote WSL-extensie je in staat om je Linux-bestandssysteem rechtstreeks te openen. Je editor draait op Windows, maar de bestanden blijven binnen WSL2.

Dit is de bedoelde workflow. Het vermijdt enigszins (niet volledig) de prestatiestraffen terwijl het uw ontwikkelervaring intact houdt. U kunt ook toegang krijgen tot WSL-bestanden via het speciale pad:

\\wsl$\YourDistro\home\youruser\projects

Wanneer je /mnt/c nog zou kunnen gebruiken

Sommige workloads profiteren nog steeds van het Windows-bestandssysteem

Om eerlijk te zijn, is het Windows-bestandssysteem in deze context niet nutteloos. Er zijn geldige gebruikssituaties, zoals het openen van documenten of mediabestanden, het delen van eenvoudige scripts tussen omgevingen, en interoperabiliteit met uitsluitend Windows-tools, maar voor actieve ontwikkeling, vooral bij alles wat grote afhankelijkheidsstructuren of frequente bestandsbewerkingen omvat, is het de verkeerde plek om je project te plaatsen. Het helpt om WSL2 niet te zien als 'Linux binnen Windows', maar als een apart Linux-systeem dat toevallig goed integreert met Windows.

Zodra je dat model aanneemt, wordt de beslissing over het bestandssysteem duidelijk. Je zou normaal gesproken een Linux-project niet ontwikkelen op een via het netwerk aangekoppeld bestandssysteem met hoge latentie. Je zou het lokaal houden. In WSL2 is het Linux-bestandssysteem je lokale omgeving en het Windows-bestandssysteem is vanuit het perspectief van Linux feitelijk extern.

Het repareren kost maar een paar minuten

Verplaats project of kloon binnen Linux-bestandssysteem

De oplossing is niet ingewikkeld. Je hoeft alleen je project te verplaatsen:

mv /mnt/c/Users/YourName/projects/my-app ~/projects/ 

Of kloon het direct opnieuw binnen WSL2:

git clone <repo>  ~/projects/my-app 

Werk uw editor bij om de nieuwe locatie te openen.

Prestaties zijn meer afhankelijk van de locatie dan van afstemming

WSL2 werkt het beste wanneer het wordt behandeld als een volledige Linux-omgeving met gerespecteerde interne grenzen. Op het moment dat een project binnen die ruimte leeft, verdwijnt het grootste deel van de wrijving die gepaard gaat met hybride workflows. Windows blijft nuttig als een interface-laag, maar de uitvoeringscontext wordt weer coherent, en de tools gedragen zich zoals ze ontworpen zijn om zich te gedragen.

Het interessante is hoe weinig inspanning nodig is om dat stadium te bereiken. Een verandering van locatie beïnvloedt de prestaties meer dan de meeste configuratieaanpassingen ooit zullen doen. Zodra dat intuïtief wordt, begint het eerdere gedrag minder op een mysterie te lijken en meer op een voorspelbaar gevolg van het kruisen van systemen die nooit geoptimaliseerd zijn voor constant heen en weer toegankelijke toegang.