Molti sviluppatori si affidano a un ambiente Sottosistema di Windows per Linux Gli strumenti Linux possono funzionare senza problemi all'interno di Windows, ma le prestazioni di questo ambiente possono deteriorarsi significativamente quando si eseguono progetti direttamente dai dischi di Windows. Ciò si manifesta spesso con un'esecuzione lenta dei comandi, un caricamento ritardato dei file o una scarsa reattività nella gestione di progetti di grandi dimensioni.
Questo calo di prestazioni è legato al modo in cui WSL2 gestisce il file system, dove i file di Windows vengono acceduti tramite un livello intermedio che influisce sulla velocità di lettura e scrittura. Maggiore è il numero di file o processi, maggiore è l'impatto, rendendo l'ambiente di sviluppo meno efficiente rispetto all'esecuzione in un sistema Linux nativo o all'interno del file system WSL2 stesso.
Fortunatamente, le prestazioni possono essere migliorate significativamente migrando i progetti al file system interno di WSL2 o adattando i flussi di lavoro a questo ambiente. Comprendere la causa principale del problema aiuta a prendere decisioni migliori e a ottenere un'esperienza di sviluppo più rapida e stabile.
Quando si inizia a utilizzare il Sottosistema Windows per Linux, tutto sembra funzionare normalmente. È possibile clonare un repository, installare le dipendenze, eseguire l'applicazione e persino convincersi di avere finalmente "Linux su Windows".
Poi si inizia a percepire che qualcosa non va e ci si accorge che i comandi che dovrebbero essere istantanei impiegano un tempo considerevole. Le installazioni dei pacchetti sono lente, i monitor dei file si comportano in modo anomalo e i server di sviluppo sembrano lenti in modi che sfuggono a una facile spiegazione. Inizialmente, la colpa viene attribuita a WSL2 stesso, ma di solito si tratta del colpevole sbagliato.
Il vero problema sta nella posizione in cui si trovano i tuoi file.
Il file system di Windows impone una penalizzazione nascosta in termini di prestazioni.
Se il tuo progetto si trova in un luogo come:
/mnt/c/Utenti/IlTuoNome/progetti/laMiaApp
Non stai lavorando davvero su file system Linux. Stai lavorando sul file system di Windows, a cui si accede tramite un livello di traduzione.
Questo dettaglio è facile da trascurare e sorprendentemente costoso. WSL2 esegue un vero kernel Linux all'interno di una macchina virtuale leggera. All'interno di questo ambiente, è presente un filesystem Linux nativo. È veloce, stabile e si comporta esattamente come ci si aspetterebbe dagli strumenti Linux.
Tuttavia, quando si accede ai file sotto /mnt/c، /mnt/dSu qualsiasi unità Windows installata, ogni processo di file deve attraversare un confine tra Linux e Windows. È proprio in questo confine che le prestazioni calano (silenziosamente, senza visualizzare errori, il che non fa altro che peggiorare la situazione).
Perché questo in realtà rallenta le cose?
I carichi di lavoro che fanno ampio uso di file aumentano il costo della traduzione del file system.
I moderni carichi di lavoro di sviluppo sono fortemente basati su file. Considera cosa succede quando esegui un'operazione come questa:
npm install
pip install
cargo build
npm run devQuesti strumenti creano, leggono e modificano migliaia di piccoli file. Si basano su un accesso rapido al file system e su un comportamento prevedibile.
Nel file system nativo di Linux, questa operazione è ottimizzata, ma nel file system di Windows accessibile tramite WSL2, ciascuna di queste operazioni comporta una traduzione tra due sistemi diversi.
Di conseguenza, le cose funzionano, ma tutto è più lento. A volte è la metà più lento, a volte dieci volte più lento e in alcuni casi può essere anche peggio. Non sempre lo si nota subito perché il rallentamento è distribuito su molti piccoli processi, ma col tempo si accumula.
Uno dei modi più semplici per individuare questo problema è usare Git. Esegui `git status` o `git checkout` su un repository di grandi dimensioni memorizzato in `/mnt/c` e confrontalo con lo stesso repository presente nella tua directory home Linux.
La differenza non è sottile: Git esegue molte operazioni sul filesystem. Analizza le directory, controlla i metadati e confronta lo stato dei file. Su un bridge di filesystem lento, questo diventa dolorosamente evidente. Spesso si tende a dare la colpa a Git stesso o a supporre che il repository sia semplicemente "troppo grande". In realtà, è la scelta del filesystem a causare la maggior parte dei problemi.
Un altro problema comune è il monitoraggio dei file non attendibili. Strumenti come Webpack, Vite o Nodemon si basano sugli eventi del file system per rilevare le modifiche. In un file system nativo di Linux, questi eventi vengono gestiti in modo efficiente.
Al di fuori dei confini di Windows, le cose diventano incoerenti.
Potresti notare:
- I cambiamenti non portano alla ricostruzione
- ricarica ritardata
- Aumento dell'utilizzo della CPU dovuto ai meccanismi di rilevamento del backup.
Questo non è un problema dei tuoi strumenti; è il risultato di come vengono tradotte le notifiche del filesystem tra Windows e Linux. Spostare il progetto sul filesystem WSL2 dovrebbe risolvere questi problemi.
Il conforto ingannevole di /mnt/c
La comodità maschera il costo dell'accesso ai sistemi
È perfettamente comprensibile il motivo per cui le persone finiscono qui. Si inizia a lavorare in Windows e i file e l'editor sono lì. Sembra naturale accedervi da WSL2 tramite /mnt/c.
Questo crea l'illusione di un ambiente unificato. Un unico file system, accessibile sia da Windows che da Linux, tranne per il fatto che non è unificato, bensì un ponte, e i ponti hanno i loro costi.
Questa configurazione è adatta per l'accesso occasionale ai file, ma non è ideale per carichi di lavoro di sviluppo intensivi che si basano su operazioni frequenti sul file system.
Quando si lavora su un filesystem Linux all'interno di WSL2, la differenza è immediata. Il percorso si presenta in questo modo:
Ora stai lavorando interamente in un ambiente Linux, senza livelli di traduzione o overhead di compatibilità tra sistemi operativi. Se, seguendo questa guida, provi a installare le dipendenze, noterai che l'installazione si completa molto più velocemente e che i server di sviluppo si avviano più rapidamente e si ricaricano in modo più affidabile.
Ma che dire dell'accesso da Windows?
Gli editor moderni supportano già i flussi di lavoro remoti su Linux.
È proprio questo il punto che genera perplessità. Se il progetto si trova all'interno di WSL2, come si fa ad aprirlo nell'editor di Windows?
La risposta è che gli strumenti moderni hanno già risolto questo problema. Se stai usando VS Code, allora Estensione WSL remota Consente di aprire direttamente il file system Linux. VS Code funziona su Windows, ma i file rimangono all'interno di WSL2.
Questo è il flusso di lavoro previsto. Evita (ma non completamente) cali di prestazioni, mantenendo intatta la tua esperienza di sviluppo. Puoi anche accedere ai file WSL tramite il seguente percorso:
wsl$YourDistrohomeyouruserprojects
Tuttavia, per lo sviluppo attivo, un approccio di integrazione remota è più pulito.
Quando potresti ancora usare /mnt/c?
Alcuni carichi di lavoro traggono ancora vantaggio dal file system di Windows.
A dire il vero, il file system di Windows non è del tutto inutile in questo contesto. Esistono casi d'uso validi, come l'accesso a documenti o file multimediali, la condivisione di semplici script tra ambienti diversi e l'interoperabilità con strumenti specifici di Windows. Tuttavia, per lo sviluppo attivo, soprattutto per progetti che coinvolgono grandi alberi di dipendenze o operazioni ripetitive sui file, non è il posto giusto dove collocare il proprio progetto. È utile pensare a WSL2 non come a "Linux all'interno di Windows", ma come a un sistema Linux separato che si integra perfettamente con Windows.
Una volta adottato questo modello, la scelta del filesystem diventa chiara. In genere, non si svilupperebbe un progetto Linux su un filesystem di rete con elevata latenza. Lo si manterrebbe in locale. In WSL2, il filesystem Linux rappresenta l'ambiente locale, mentre il filesystem Windows è virtualmente remoto dal punto di vista di Linux.
Ripararlo richiede pochi minuti
Trasferisci o clona il progetto all'interno del file system Linux.
La soluzione non è complicata. Tutto ciò che devi fare è spostare il tuo progetto:
mv /mnt/c/Users/YourName/projects/my-app ~/projects/ Oppure clonalo direttamente all'interno di WSL2:
git clone <repo> ~/projects/my-app Aggiorna il tuo editor di codice per aprire il nuovo sito.
Le prestazioni dipendono più dalla posizione che dalle impostazioni.
WSL2 funziona al meglio quando viene trattato come un ambiente Linux completo, rispettandone i limiti interni. Una volta che un progetto si sviluppa all'interno di questo framework, la maggior parte delle difficoltà associate ai flussi di lavoro ibridi scompare. Windows rimane utile come livello di interfaccia, ma il contesto di implementazione riacquista coerenza e gli strumenti si comportano come sono stati progettati.
L'aspetto interessante è la minima difficoltà richiesta per raggiungere questo stato. Cambiare posizione influisce sulle prestazioni più di quanto non facciano la maggior parte delle modifiche alla configurazione. Una volta che questo diventa intuitivo, il comportamento precedente inizia a sembrare meno misterioso e più una conseguenza prevedibile della navigazione in sistemi che non sono mai stati ottimizzati per un accesso continuo avanti e indietro.
