Diagnostic de performance du devcontainer

Avant de commencer : ce module ne produit pas les mêmes chiffres pour tout le monde

Le ralentissement classique des I/O en devcontainer — un npm install ou une suite de tests visiblement plus lents dans le conteneur qu'en dehors — est principalement un phénomène Docker Desktop (macOS/Windows) ou WSL2 avec les fichiers du projet stockés côté Windows. Un environnement Linux natif (le conteneur tourne directement sur le noyau Linux de la machine, sans traduction de système de fichiers via une VM) ne reproduit généralement pas ce symptôme au même degré, parce que le bind mount va directement au système de fichiers hôte sans la couche de traduction qui cause le ralentissement ailleurs.

Concrètement :

• Si vous êtes sur Docker Desktop (macOS/Windows) ou WSL2 avec vos fichiers de projet sous /mnt/c/... : vous pouvez reproduire ce diagnostic avec de vrais chiffres, suivez la méthode ci-dessous telle quelle.
• Si vous êtes sur Linux natif : lisez quand même la méthode, mais attendez-vous à ce que vos mesures ne montrent pas de différence significative — c'est un résultat valide, pas un échec de l'exercice. Raisonnez sur ce que vous attendriez de mesurer dans l'environnement décrit, et notez pourquoi votre environnement diffère.

La méthode : mesurer → hypothèse → tester → vérifier

1. Mesurer

Le symptôme signalé : npm install (ou une commande équivalente à charge I/O élevée — beaucoup de petits fichiers) est nettement plus lent dans le devcontainer qu'en dehors. Quantifiez, ne vous fiez pas à une impression :

# à l'intérieur du devcontainer
rm -rf node_modules
time npm install

# sur l'hôte, en dehors de tout conteneur, si le même toolchain y est disponible
rm -rf node_modules
time npm install

Notez les deux temps réels (real). Sur Docker Desktop ou WSL2-avec-fichiers-Windows, un écart de plusieurs fois (2x à 10x, selon la doc communautaire et l'expérience de terrain — pas un chiffre officiellement garanti par Microsoft) est plausible pour un projet avec beaucoup de petits fichiers (typiquement node_modules, avec des dizaines de milliers d'entrées).

2. Hypothèse

Si votre projet vit dans un dossier bind-mounté depuis le système de fichiers Windows (/mnt/c/... vu depuis WSL, ou un dossier C:\Users\... monté dans Docker Desktop), l'hypothèse à tester est : chaque accès fichier depuis le conteneur traverse une couche de traduction supplémentaire (le pont WSL2 vers NTFS, ou le partage de fichiers de Docker Desktop) qui ajoute une latence par opération — négligeable pour un seul gros fichier, mais qui s'accumule sur des dizaines de milliers de petites opérations comme celles d'un npm install.

3. Tester

Sur WSL2 spécifiquement, la documentation officielle Microsoft sur les systèmes de fichiers donne la marche à suivre. Elle recommande explicitement, pour la meilleure vitesse depuis une ligne de commande Linux :

« For the fastest performance speed, store your files in the WSL file system if you are working in a Linux command line (Ubuntu, OpenSUSE, etc). »

Et précise ce qu'il faut éviter :

« Use the Linux file system root directory: /home/<user name>/Project — Not the Windows file system root directory: /mnt/c/Users/<user name>/Project »

Le préfixe /mnt/ est le signal : dès que vous le voyez dans un chemin depuis WSL, vous accédez à un disque monté (le système de fichiers Windows), pas au système de fichiers Linux natif de la distribution.

Déplacez votre projet et refaites la mesure :

# clonez (ou copiez) le projet dans le système de fichiers Linux natif
cd ~
git clone <votre-repo> project-linux-native
cd project-linux-native

rm -rf node_modules
time npm install

Si votre devcontainer est ouvert depuis ce nouveau chemin (~/project-linux-native, pas /mnt/c/...), le bind mount du conteneur pointe maintenant vers le système de fichiers Linux natif de WSL2, sans traversée /mnt/.

4. Vérifier

Comparez les trois temps : hôte natif hors conteneur, conteneur avec projet sous /mnt/c/..., conteneur avec projet dans le système de fichiers Linux natif. La vérification réussie ressemble à :

• Hôte hors conteneur : X secondes
• Conteneur, projet sous /mnt/c/... : significativement plus lent que X
• Conteneur, projet dans le système de fichiers Linux : proche de X, nettement plus rapide que la version /mnt/c/...

Si le troisième chiffre se rapproche du premier, votre hypothèse est confirmée : la traversée /mnt/ était bien le facteur dominant, pas Docker ou le devcontainer lui-même.

Si vous êtes sur Linux natif

Reprenez la même méthode, mais en conscience que l'étape 3 ne s'applique pas de la même façon : sur Linux natif, il n'y a pas de traversée /mnt/ équivalente — un bind mount Docker sur Linux natif accède au système de fichiers hôte directement, via les mêmes appels système que n'importe quel processus. Si vous mesurez malgré tout un écart significatif entre hôte et conteneur sur Linux natif, la cause probable est ailleurs : un .dockerignore absent qui laisse le contexte de build gonfler, un volume Docker (plutôt qu'un bind mount) qui aurait un comportement différent, ou un cgroup/limite de ressources (CPU, mémoire) imposée au conteneur qui ralentit indirectement le CPU-bound work d'un npm install (résolution de dépendances). Documentez cette hypothèse alternative et testez-la de la même façon — mesurer, hypothèse, tester, vérifier — plutôt que de conclure "le bind mount est toujours lent" sans preuve spécifique à votre environnement.

Ce que ce module ne garantit PAS

Ne présentez pas un chiffre précis ("2x plus lent", "5x plus lent") comme une vérité universelle — ces écarts dépendent de la version de Docker Desktop, de la configuration WSL2, du nombre de fichiers du projet, et évoluent avec les versions des outils (par exemple, les backends de partage de fichiers plus récents de Docker Desktop réduisent cet écart par rapport aux anciennes versions). Ce que ce module garantit, c'est la méthode et la direction du principe documenté par Microsoft — pas un chiffre fixe à mémoriser.

Ce qui vous attend au module suivant

Vous avez maintenant construit, miroité en CI, audité et optimisé un setup pour un seul repo. Le module final vous demande de raisonner sur un problème sans réponse officielle établie : comment standardiser tout ça à l'échelle d'une organisation entière.