Environ 4 mois après la publication de .NET 5, Microsoft a annoncé jeudi dans un billet de blogue qu'il a constaté que les développeurs et les entreprises sont nombreux à migrer vers la première version de sa plateforme unifiée .NET 5. Cette vague de migration concernerait essentiellement de grandes solutions écrites avec .NET Framework. Pour faciliter la tâche aux développeurs, Microsoft a annoncé qu'il a optimisé l'EDI Visual Studio 2019 16.8 sur cinq différents points pour qu'il puisse traiter des solutions contenant un grand nombre de projets .NET 5 et .NET Core. Voici ci-dessous un aperçu des différentes mises à jour..NET 5 : une unification des différents outils de la plateforme .NET
Microsoft annonçait en 2019 l'arrivée de .NET 5, qui, selon l'entreprise, sera son premier grand produit sur la voie de l'unification de la plateforme .NET. Après près de deux ans de développement, Microsoft a publié .NET 5 en novembre dernier. .NET 5 représente la première version de cet effort d'unification des différentes variantes de .NET à travers les systèmes d'exploitation, le Web et une variété de facteurs de forme. .NET 5 succède ainsi à .NET Core 3.X. Microsoft a rassuré que le .NET Framework existant reste un produit qu'il continuera de mettre à jour avec chaque nouvelle version de Windows.
Rappelons qu'en 2020, il a cessé d'ajouter de nouvelles fonctionnalités à .NET Framework à partir de la version 4.8 et a aussi fini d'ajouter les API du .NET Framework au .NET Core. Il ne prévoit pas non plus de publier une nouvelle version de .NET Standard. L'entreprise a annoncé la fin de .NET Standard pendant l'été 2020, mais elle a aussi précisé que .NET 5 et toutes les versions futures continueront à prendre en charge le .NET Standard 2.1 et les versions antérieures. .NET 5 fournit aux développeurs des outils, des interfaces de programmation, des fonctionnalités d'exécution et de nouveaux langages.
C'est ce que Microsoft préconise aux développeurs d'utiliser pour créer des interfaces utilisateur Web et des services de backend. « Nous avions l'intention de réaliser l'intégralité de la vision d'unification avec .NET 5.0, mais dans le sillage de la pandémie mondiale, nous avons dû nous adapter à l'évolution des besoins de nos clients », ont déclaré les responsables dans le billet de blogue annonçant la sortie de .NET 5. Les développeurs semblent avoir suivi les recommandations de l'entreprise, car elle a annoncé jeudi que beaucoup d'entre eux migrent déjà vers .NET 5. Elle veut donc faciliter cela à travers une optimisation de Visual Studio.
Exécution du compilateur C# et VB en dehors du processus
Selon Paul Vick, ingénieur logiciel principal de l'équipe de développement de Visual Studio, Roslyn, le compilateur C# et Visual Basic, analyse la solution complète pour alimenter des services tels qu'IntelliSense, "Go to Definition", et les diagnostics/erreurs. Ainsi, Roslyn a tendance à consommer des ressources qui augmentent proportionnellement à la taille de la solution ouverte, ce qui peut devenir assez important pour les grandes solutions. Il estime qu'un travail a déjà été fait sur Roslyn pour minimiser cet impact en mettant en cache de manière agressive sur le disque des informations qui ne sont pas immédiatement nécessaires.
Cependant, même avec cette mise en cache, elle ne peut pas échapper à la nécessité de conserver les données en mémoire. De ce fait, Vick a déclaré qu'afin de réduire son impact sur les solutions Visual Studio de plus grande envergure, l'équipe Roslyn a déployé des efforts considérables pour sortir le compilateur Roslyn du processus Visual Studio et l'intégrer à son propre processus. L'utilisation de Roslyn dans son propre processus libère des ressources au sein de Visual Studio lui-même et permet au compilateur Roslyn d'avoir plus de place pour faire son travail.
D'après ce qu'il dit, pour les solutions de grande taille, cela peut permettre d'économiser jusqu'à un tiers de la mémoire consommée par Visual Studio lorsque vous ouvrez une solution de grande taille.
Rationalisation du nœud Dependencies
La deuxième optimisation apportée par l'équipe à Visual Studio consiste en la rationalisation du nœud "Dependencies" (Dependencies node). En effet, Vick a expliqué que chaque projet .NET 5 et .NET Core possède un nœud dans l'explorateur de solutions appelé "Dépendances" qui affiche toutes les choses dont le projet dépend : autres projets, assemblages, paquets NuGet, etc. En plus de montrer les dépendances immédiates du projet, le nœud montre également les dépendances transitives du projet, c'est-à-dire toutes les choses dont chaque dépendance dépend, etc.
D'après l'ingénieur, l'inconvénient qui en résulte est qu'avec un projet de toute taille raisonnable, cette liste de dépendances transitives peut devenir assez grande. Mais ce n'est pas tout, Vick note également un deuxième inconvénient à la manière dont ce noeud fonctionne. Il estime que la mise en œuvre initiale du nœud "Dépendances" n'était pas particulièrement efficace dans la manière dont elle stockait les informations sur les dépendances transitives en mémoire. Elle conservait beaucoup plus d'informations que nécessaire et la plupart des données étaient redondantes.
Ainsi, pour corriger le tir, l'équipe de développement de l'EDI a réécrit le code pour ne conserver que les informations absolument nécessaires, et a commencé à utiliser les informations existantes sur les dépendances déjà conservées par NuGet. Le porte-parole de l'équipe a annoncé que cette réécriture permet d'économiser jusqu'à 10-15 % de la mémoire consommée par Visual Studio lorsque vous ouvrez une solution de grande envergure.
Réduire les doublons dans MSBuild
Selon Vick, Visual Studio s'appuie sur plusieurs outils qui s'avèrent être voraces en mémoire. Outre, Roslyn, il a déclaré que l'un des autres grands consommateurs de ressources dans un processus de studio visuel est MSBuild. En effet, en tant que moteur de construction, une grande partie de l'expérience de l'IDE est alimentée par le modèle objet de MSBuild. Pour résoudre ce problème, l'équipe a rendu les fichiers de projet eux-mêmes beaucoup plus petits dans .NET 5 et .NET Core. Cela dit, il existe un nombre important de fichiers de projet qui sont importés dans les projets via le SDK.
Vick a déclaré que l'évaluation de tous ces fichiers est nécessaire pour comprendre et construire un projet, et peut consommer jusqu'à un autre tiers de la mémoire consommée par Visual Studio lorsque vous ouvrez une grande solution. Il continue en disant que, bien que les fichiers de projet génèrent beaucoup de données, une grande partie de ces données sont répétitives et l'équipe a choisi de les dupliquer en mémoire. Les chaînes de caractères sont l'un des sous-produits les plus courants du système de projet, et elles stockent des informations comme les noms de fichiers, les options et les chemins d'accès.
Les chemins, en particulier, peuvent être assez longs et peuvent finir par consommer beaucoup de mémoire s'ils sont trop nombreux ou s'ils sont dupliqués trop souvent. En veillant à ne conserver qu'une seule copie d'une chaîne, il est possible d'économiser de 5 à 10 % de la mémoire consommée par Visual Studio lorsqu'on ouvre une grande solution.
Réduire les copies de projet conservées par le système de projet
Vick a expliqué que l'un des aspects importants de la conception du système de projet .NET 5 et .NET Core est l'asynchronie (asynchrony). Souvent, le système de projet doit effectuer un travail en réponse à une action de l'utilisateur (par exemple, ajouter une nouvelle référence à un projet). Au lieu de bloquer Visual Studio pendant qu'il termine son travail, le système de projet permet à l'utilisateur de continuer à travailler dans l'EDI et de faire le travail en arrière-plan, par exemple, en ajoutant une nouvelle référence.
Comme l'utilisateur peut modifier un projet alors que le système de projet traite des modifications précédentes en arrière-plan, le système de projet doit enregistrer des instantanés des données du projet pour s'assurer qu'une action ultérieure n'entre pas en conflit avec une action précédente. Par conséquent, le système de projet peut facilement se retrouver avec plusieurs copies des données d'un projet en mémoire à la fois. Si le système de projet ne prend pas soin de gérer ces copies, elles peuvent être conservées plus longtemps que nécessaire, voire faire l'objet de fuites et être conservées de manière permanente.
Vick a annoncé que son équipe et lui sont conscients des problèmes que cela peut poser et travaillent donc avec acharnement pour réduire le nombre de copies que le système de projet peut conserver en une fois.
Amélioration de la charge de solution
« Avec tout ce travail, nous avons considérablement optimisé l'expérience de travail avec les grandes solutions .NET 5 et .NET Core », a déclaré Vick. « À partir de la version 16.8, nous avons constaté, dans nombre de nos tests, une amélioration de 2,5 fois de la taille de la solution que nous pouvons ouvrir avant de rencontrer des problèmes de ressources. Nous avons également constaté une diminution allant jusqu'à 25 % des pannes signalées en raison de l'épuisement des ressources », a ajouté l'ingénieur.
Selon lui, les améliorations énumérées ci-dessus ne sont que le début des changements que nous apportons pour améliorer l'expérience de travail avec des solutions de grande taille dans Visual Studio. Toutefois, il note que les performances des solutions individuelles peuvent encore varier, en fonction de la taille de la solution, du type de projets, des extensions chargées, etc. Il invite donc les développeurs qui rencontreront d'autres problèmes à contacter l'équipe pour une assistance.
Source : Microsoft
Et vous ?
Que pensez-vous des optimisations apportées à Visual Studio ? Avez-vous déjà migré ou entamé la migration de votre projet vers .NET 5 ? Quels sont les problèmes que vous et votre organisation avez rencontrés lors de la migration ?Voir aussi
Microsoft a annoncé la disponibilité générale de .NET 5 qui inclut C# 9, F# 5 et une prise en charge native de Windows Arm64 Depuis qu'il a effectué une migration vers .NET 5.0, le développeur de la bibliothèque .NET Fusion a constaté une nette amélioration des performances Avec .NET 5, Microsoft voudrait produire un environnement d'exécution .NET unique et une infrastructure utilisable partout .NET 5 : Benchmark.NET est dorénavant l'outil canonique pour mesurer la performance du code .NET. Voici un aperçu des améliorations de performances à venir dans .NET 5 
.
.
.
Envoyé par vanquish
