De nombreux développeurs s'appuient sur un environnement Sous-système Windows pour Linux Les outils Linux fonctionnent correctement sous Windows, mais les performances de cet environnement peuvent se dégrader considérablement lors de l'exécution de projets directement depuis les disques Windows. Cela se traduit souvent par une exécution lente des commandes, un chargement des fichiers retardé ou une faible réactivité lors de la gestion de projets volumineux.
Cette baisse de performance est liée à la façon dont WSL2 gère le système de fichiers : l’accès aux fichiers Windows se fait via une couche intermédiaire qui impacte les vitesses de lecture et d’écriture. Plus le nombre de fichiers ou de processus est élevé, plus l’impact est important, ce qui rend l’environnement de développement moins efficace qu’une exécution sur un système Linux natif ou directement au sein du système de fichiers WSL2.
Heureusement, les performances peuvent être considérablement améliorées en migrant les projets vers le système de fichiers interne de WSL2 ou en adaptant les flux de travail à cet environnement. Comprendre la cause profonde du problème vous permet de prendre de meilleures décisions et de bénéficier d'une expérience de développement plus rapide et plus stable.
Lorsque vous commencez à utiliser le Sous-système Windows pour Linux, tout semble fonctionner normalement. Vous pouvez cloner un dépôt, installer des dépendances, exécuter votre application et même vous convaincre que vous disposez désormais de « Linux sur Windows ».
On se rend compte alors que quelque chose cloche : des commandes qui devraient être instantanées prennent un temps considérable. L’installation des paquets est lente, les moniteurs de fichiers se comportent de manière erratique et les serveurs de développement semblent anormalement lents, sans qu’on puisse l’expliquer. Au départ, on incrimine WSL2, mais c’est généralement une erreur.
Le véritable problème réside dans l'emplacement de vos fichiers.
Le système de fichiers Windows impose une pénalité de performance cachée.
Si votre projet est situé dans un endroit comme :
/mnt/c/Utilisateurs/VotreNom/projets/mon-app
Vous ne travaillez pas vraiment sur système de fichiers Linux. Vous travaillez sur le système de fichiers Windows, auquel vous accédez via une couche de traduction.
Ce détail est facile à négliger et pourtant étonnamment coûteux. WSL2 exécute un véritable noyau Linux au sein d'une machine virtuelle légère. Cet environnement contient un système de fichiers Linux natif. Il est rapide, stable et se comporte exactement comme on peut s'y attendre des outils Linux.
Cependant, lorsque vous accédez aux fichiers sous /mnt/c، /mnt/dSur tout disque Windows installé, chaque processus de fichier doit franchir une frontière entre Linux et Windows. C'est à ce niveau que les performances chutent (silencieusement, sans afficher d'erreurs, ce qui ne fait qu'empirer les choses).
Pourquoi cela ralentit-il les choses ?
Les charges de travail nécessitant une manipulation intensive de fichiers augmentent le coût de la traduction du système de fichiers.
Les environnements de développement modernes sont fortement axés sur les fichiers. Prenons l'exemple d'une commande comme :
npm install
pip install
cargo build
npm run devCes outils créent, lisent et modifient des milliers de petits fichiers. Ils reposent sur un accès rapide au système de fichiers et un comportement prévisible.
Sur le système de fichiers Linux natif, cela est optimisé, mais sur le système de fichiers Windows accessible via WSL2, chacune de ces opérations implique une traduction entre deux systèmes différents.
En conséquence, tout fonctionne, mais plus lentement. Parfois, c'est deux fois plus lent, parfois dix fois plus, et dans certains cas, c'est même pire. On ne s'en aperçoit pas toujours immédiatement car le ralentissement est réparti sur de nombreux petits processus, mais avec le temps, il s'accumule.
L'un des moyens les plus simples de repérer ce problème est d'utiliser Git. Exécutez `git status` ou `git checkout` sur un dépôt volumineux stocké sous `/mnt/c`, et comparez-le au même dépôt situé dans votre répertoire personnel Linux.
La différence est flagrante : Git effectue de nombreuses opérations sur le système de fichiers. Il analyse les répertoires, vérifie les métadonnées et compare l’état des fichiers. Sur un pont système de fichiers lent, cela devient criant. On a souvent tendance à incriminer Git ou à supposer que le dépôt est simplement « trop volumineux ». En réalité, c’est le choix du système de fichiers qui est à l’origine de la plupart des problèmes.
Un autre problème courant concerne la surveillance des fichiers non fiables. Des outils comme Webpack, Vite ou Nodemon s'appuient sur les événements du système de fichiers pour détecter les modifications. Dans un système de fichiers Linux natif, ces événements sont gérés efficacement.
Au-delà des limites de Windows, les choses deviennent incohérentes.
Vous remarquerez peut-être :
- Les changements n'entraînent pas la reconstruction.
- rechargement retardé
- Augmentation de l'utilisation du processeur due aux mécanismes de sonde de secours
Ce problème ne provient pas de vos outils ; il est dû à la manière dont les notifications du système de fichiers sont traduites entre Windows et Linux. Le déplacement du projet vers le système de fichiers WSL2 devrait résoudre ces problèmes.
Le confort trompeur de /mnt/c
La commodité masque le coût d'accès aux systèmes
Il est parfaitement compréhensible que l'on se retrouve ici. On commence à travailler sous Windows, et nos fichiers et notre éditeur sont là. Il semble donc naturel d'y accéder depuis WSL2 via /mnt/c.
Cela donne l'illusion d'un environnement unifié : un système de fichiers unique, accessible depuis Windows et Linux. Sauf qu'il ne s'agit pas d'un environnement unifié, mais plutôt d'un pont, et les ponts ont leurs inconvénients.
Cette configuration convient pour un accès occasionnel aux fichiers, mais n'est pas adaptée aux charges de travail de développement actives qui reposent sur des opérations fréquentes sur le système de fichiers.
Lorsque vous travaillez sur un système de fichiers Linux dans WSL2, la différence est immédiate. Votre chemin d'accès ressemble à ceci :
Vous travaillez désormais entièrement dans un environnement Linux, sans couche de traduction ni surcharge liée à l'interopérabilité. Dans ce guide, si vous installez des dépendances, vous constaterez que l'installation est beaucoup plus rapide et que les serveurs de développement démarrent plus vite et se rechargent de manière plus fiable.
Mais qu'en est-il de l'accès depuis Windows ?
Les logiciels de montage modernes prennent déjà en charge les flux de travail Linux à distance.
C’est ce point qui suscite des hésitations. Si votre projet se trouve dans WSL2, comment l’ouvrir dans votre éditeur Windows ?
La réponse est que les outils modernes ont déjà résolu ce problème. Si vous utilisez VS Code, alors Extension WSL à distance Il vous permet d'ouvrir directement votre système de fichiers Linux. VS Code fonctionne sous Windows, mais les fichiers restent confinés dans WSL2.
Voici le flux de travail prévu. Il permet d'éviter (mais pas totalement) les pertes de performance tout en préservant votre expérience de développement. Vous pouvez également accéder aux fichiers WSL via le chemin suivant :
\wsl$VotreDistrohomevosprojetsutilisateur
Mais pour le développement actif, une approche d'intégration à distance est plus propre.
Quand pourriez-vous encore utiliser /mnt/c
Certaines charges de travail tirent encore profit du système de fichiers Windows.
Il faut reconnaître que le système de fichiers Windows n'est pas inutile dans ce contexte. Il présente des cas d'utilisation pertinents, comme l'accès à des documents ou des fichiers multimédias, le partage de scripts simples entre environnements et l'interopérabilité avec des outils propres à Windows. Cependant, pour un développement actif, notamment pour tout projet impliquant des arborescences de dépendances importantes ou des opérations de fichiers répétitives, il n'est pas adapté. Il est préférable de considérer WSL2 non pas comme un « Linux au sein de Windows », mais comme un système Linux distinct qui s'intègre parfaitement à Windows.
Une fois ce modèle adopté, le choix du système de fichiers devient évident. On ne développe généralement pas un projet Linux sur un système de fichiers réseau à latence élevée ; on le garde en local. Dans WSL2, le système de fichiers Linux constitue votre environnement local, tandis que le système de fichiers Windows est virtuellement distant du point de vue Linux.
La réparation prend quelques minutes
Transférez ou clonez le projet au sein du système de fichiers Linux.
La solution est simple. Il vous suffit de déplacer votre projet :
mv /mnt/c/Users/YourName/projects/my-app ~/projects/ Ou clonez-le directement dans WSL2 :
git clone <repo> ~/projects/my-app Mettez à jour votre éditeur de code pour ouvrir le nouveau site.
Les performances dépendent davantage de l'emplacement que des paramètres.
WSL2 fonctionne de manière optimale lorsqu'il est considéré comme un environnement Linux complet, en respectant ses limites internes. Une fois un projet intégré à ce cadre, la plupart des difficultés liées aux flux de travail hybrides disparaissent. Windows reste utile comme couche d'interface, mais le contexte d'implémentation retrouve sa cohérence et les outils fonctionnent comme prévu.
Le plus étonnant, c'est la facilité avec laquelle on y parvient. Changer de localisation a un impact bien plus important sur les performances que la plupart des réglages de configuration. Une fois ce principe assimilé, le comportement précédent paraît moins mystérieux et davantage une conséquence logique de la navigation dans des systèmes qui n'ont jamais été conçus pour des allers-retours constants.
