<ul>
<li>
<p>Les Dev Drives de Windows offrent des performances améliorées pour les flux de travail de développement en faisant <em>moins</em>, en fait. La principale différence est que divers filtres/hooks du système de fichiers ne s’exécutent pas sur le Dev Drive, notamment en mettant la protection antivirus en temps réel de Windows Defender dans un mode d’opération moins hyperactif (mais également moins sécurisé). La sérialisation et le blocage des entrées/sorties par Windows Defender est la source principale de la lenteur des E/S spécifique à Windows. Ce n’est pas (principalement) ReFS qui offre les performances améliorées, c’est le reste du réglage effectué par défaut pour les partitions Dev Drive. (Cela rend ce réglage plus pratique cependant, d’après ce que je comprends.)</p>
</li>
<li>
<p>Cela pourrait aider dans d’autres scénarios, mais c’est peu probable. Le gain de performances en E/S est principalement dû à la minimisation du surcoût par opération, en particulier lors de la création/écriture parallèle de petits fichiers. Les jeux regroupent généralement leurs ressources et ont des modèles de lecture séquentielle de gros blocs au lieu des modèles en rafales observés dans les flux de travail de développement.</p>
</li>
<li>
<p>Le Dev Drive de Windows consiste à rapprocher les performances du système de fichiers Windows de celles du système de fichiers Linux. Linux gère son système de fichiers très différemment de Windows, et par conséquent, Linux est beaucoup plus performant dans les flux de travail de développement avec beaucoup de petits fichiers que Windows, même en utilisant un Dev Drive. Parce que le Dev Drive consiste à ajuster des propriétés spécifiques au système de fichiers Windows, les techniques utilisées ici sont très peu susceptibles de s’appliquer aux systèmes de fichiers d’autres systèmes d’exploitation.</p>
</li>
</ul>