si je met mes fichier sur la partition windows et non dans /home ou /var c'est tres lent Mais c'est peut-etre un soucis de linux pour la lecture ntfs et pas specialement le bash windows.
Une partie de la différence peut venir d'une certaine lenteur traditionnelle des lectures et écritures de fichiers par Windows dans le filesystem NTFS.
Il y a des années - du temps de Vista, parce que c'était un descendant de XP mais c'était avant Seven - j'avais vu passer que les nombres de performance de tests d'accès filesystem produits par un programme de benchmark type Sandra Bench étaient bien meilleurs sous Wine sous Linux que sous Windows natif, de mémoire plus de +100% meilleurs, sans que ce soit un pur effet d'affichage...
Aussi, Git fait une large utilisation des syscalls de la famille stat() sous Linux, où ils sont rapides, alors que les équivalents Windows, dont j'ai oublié le nom, sont comparativement lents, rendant Git traditionnellement comparativement lent sous Windows.
Et en voyant, en 2015-2016, les temps que les machines Windows Seven des collègues mettaient à réaliser les `npm install`, par rapport au temps que ma machine Linux de même modèle mettait, je dirais qu'une relative lenteur des accès disque NTFS persiste sur des versions contemporaines de Windows.
Par contre ce serait bien qu'ils mettent a jour le kernel, 3.4 c'est un peu vieux ya des trucs ca peut etre limite (genre docker).
Ouais, 3.4 est carrément vieux maintenant, même s'il est encore fréquent sur les Android, hélas. Je crois que j'avais vu que les efforts de Microsoft pour le subsystem Linux avaient commencé dans un projet visant à apporter une compatibilité avec Android (Project Astoria ?), c'est (en partie ?) de là que vient ce verrouillage à une version 3.4.
Maintenant qu'il y a un Docker "natif" Windows utilisant un unikernel, l'intérêt pratique d'utiliser le WSL pour tourner un Docker Linux semble moindre.
Entre autres manques, le kernel 3.4 est bien trop vieux pour avoir le syscall seccomp().