Microsoft fait le point sur ses contributions dans les performances de Git en 2017

Quelle est celle qui vous intéresse le plus ?

En février 2017, Microsoft a annoncé que son équipe de développement de Windows allait passer à l’utilisation du système de contrôle de version open source Git notamment en raison de Git Virtual File System (GVFS). Brian Harry, Vice President for Cloud Developer Services chez Microsoft, a expliqué que « GVFS, couplé à un ensemble d’améliorations à Git, permet à Git d’échelonner de TRÈS gros dépôts en virtualisant le dossier .git et le répertoire de travail. Plutôt que de télécharger l’intégralité du dépôt et de cocher tous les fichiers, il se limite à télécharger de manière dynamique les portions dont vous avez besoin en fonction de ce que vous utilisez. »

Trois mois plus tard, Microsoft a publié un billet par l’entremise de Brian Harry où l’entreprise fait le point.

Avant tout, il a rappelé que la base de code Windows comporte environ 3,5 millions de fichiers et, lorsqu’elle est enregistrée dans un compte Git, cet ensemble donne lieu à un dépôt de 300 Go. En outre, l’équipe de Windows compte environ 4000 ingénieurs et le système d’ingénierie produit 1760 « compilations de laboratoire » quotidiennes sur 440 branches en plus de milliers de compilations de validation de pull request.

Le passage à Git a été influencé par un certain nombre de choses. En 2013, la société a entrepris son projet OneCore, unifiant ses différents domaines du développement de Windows et faisant en sorte que le système d’exploitation soit une plateforme en couches plus modulaire. À l’époque, Microsoft utilisait Source Depot, une version personnalisée du système de contrôle de la version Perforce commercial, pour tous ses projets majeurs.

En novembre, Microsoft a annoncé travailler en collaboration avec GitHub pour porter son GVFS sur macOS et Linux. « Beaucoup de choses se sont passées depuis que nous avons annoncé notre intention de développer GVFS pour le dépôt Windows », s’est réjoui Brian Harry,Vice President for Cloud Developer Services chez Microsoft. Avec Git Virtual File System (GVFS), plutôt que de télécharger l’intégralité du dépôt et de cocher tous les fichiers, le système se limite à télécharger de manière dynamique les portions dont vous avez besoin en fonction de ce que vous utilisez.

Un système qui a donc intéressé plusieurs entités disposant d’énormes bases de code, mais qui était limité jusque là à Windows 10 (Anniversary Update au minimum). Cependant, Microsoft a annoncé que ce système sera bientôt disponible sur d’autres plateformes : « GitHub a annoncé qu’ils travaillaient sur l’ajout de la prise en charge de GVFS, rendant le Git évolutif disponible pour l’ensemble du monde open source. Ils vont également travailler en étroite collaboration avec nous pour améliorer encore GVFS et l’apporter aux utilisateurs Mac et Linux », a assuré Harry.

En ce début d’année, Microsoft veut faire le point sur ses contributions à Git.

« Visual Studio Team Services (VSTS) héberge le plus grand référentiel Git au monde : le code source de Windows. Garder une copie primaire du code disponible dans le cloud et la rendre performante tout en étant mis à jour par plus de 4000 utilisateurs en même temps est une réalisation monumentale, mais elle n’est utile que si les ingénieurs peuvent utiliser le client Git principal sur leurs machines. Nous avons rendu cela possible en construisant GVFS.

« Le référentiel Windows est plus important que n’importe quel autre référentiel Git par ordre de grandeur, ce qui a révélé quelques problèmes de performances dans Git principal que nous devions résoudre pour le faire fonctionner avec les grands référentiels que nous voyons chez Microsoft. Grâce au fait que Git est open source, nous avons pu l’améliorer pour tous les utilisateurs, sur toutes les plateformes en contribuant à ces modifications », a avancé Derick Stolee de Microsoft.

« En revenant sur ce que nous avons accompli en 2017, je voulais partager les détails de certains de mes patchs préférés sur lesquels nous avons travaillé avec la communauté Git au cours de l’année écoulée », a-t-il annoncé.

L’index

L’index Git est une liste de tous les fichiers du hachage actuel et de l’objet attendu basé sur la zone de transfert actuelle. De nombreuses opérations Git chargent cet index en mémoire avant d’effectuer l’action demandée. Microsoft a trouvé plusieurs façons d’accélérer les interactions d’index.

« L’index est une liste ordonnée de chemins. Sur chaque chargement d’index, Git vérifiait que la liste était toujours ordonnée. En sautant cette vérification, nous pouvons accélérer la charge d’index de 18 %. Lorsque l’index est reconstruit, les chemins sont écrits dans le bon ordre. Git vérifie les doublons sur les insertions, mais les doublons apparaissent consécutivement. En vérifiant la dernière entrée avant d’effectuer une recherche binaire, nous avons accéléré l’écriture d’index jusqu’à 20 %. Nous avons également réduit la fréquence à laquelle Git rejetait et rechargeait l’index. »

Status et Checkout

Deux des commandes Git les plus utilisées sont Status et Checkout , la première examine l’état du répertoire de travail pour voir ce qui est différent du HEAD actuel tandis que la seconde met à jour le répertoire de travail pour correspondre à un nouveau HEAD. Ces opérations sont appelées fréquemment, mais sont également très coûteuses lorsque vous travaillez sur de grands référentiels.

« De nombreux outils, tels que Visual Studio Team Explorer, utilisent status pour présenter la liste des modifications disponibles pour la validation. Beaucoup de projets ont de grands répertoires remplis d’artefacts de builds qui sont ignorés par status en raison des fichiers .gitignore. Team Explorer utilise des indicateurs spéciaux pour afficher ces fichiers ignorés, mais cette liste peut être beaucoup plus grande que les fichiers importants. Nous avons ajouté de nouveaux drapeaux à status pour rendre cet appel plus rapide et maintenant d’autres outils peuvent également utiliser ces options. Pendant que nous examinions ce code, nous avons trouvé des moyens d’améliorer les performances de l’état git – jusqu’à 50 %.

« Même avec ces accélérations, nous devons toujours parcourir le système de fichiers pour trouver l’état actuel des fichiers écrits. En fait, nous en AVIONS besoin. Nous avons ajouté un plug-in de surveillance de système de fichiers à git qui fournit à git une commande externe qui présente un instantané des changements du système de fichiers. Bien que nous nous concentrions sur l’intégration avec GVFS, cela peut aussi fonctionner avec des outils comme Watchman. »

Dans la même rubrique

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ... | 34 |

Actu en image