Microsoft annonce la première version candidate de .NET 7,

Testé avec Visual Studio 17.4 Preview 2

Le 15 septembre 2022 à 08:06, par Bruno

3PARTAGES

Microsoft a publié en août .NET 7 Preview 7. L'entreprise a annoncé qu'il s'agit du dernier aperçu de .NET 7 et que la prochaine version sera la première release candidate (RC). Cet aperçu de .NET 7 comprenait des améliorations de System.LINQ, des permissions de fichiers Unix, des structures de bas niveau, de la génération de sources p/Invoke, de la génération de code et des websockets. Aujourd’hui, Jeremy Likness, Angelos Petropoulos, Jon Douglas, membres de l’équipe de .NET de Microsot ont annoncé .NET 7 Release Candidate 1.

.NET 7 est le .NET le plus rapide à ce jour. Plus d'un millier d'améliorations ayant un impact sur les performances ont été apportées à .NET 7, notamment en ce qui concerne la réflexion, le remplacement des piles (OSR), le temps de démarrage, l'AOT natif, l'optimisation des boucles et de nombreux autres domaines.

Lorsque le développement de .NET 7 a commencé, Microsoft a expliqué à la communauté que cette nouvelle version unifiera enfin tous les composants disparates des outils de développement .NET, permettant aux développeurs de créer tous les types d'applications - bureautiques, mobiles, Web et autres - sur la même bibliothèque de classes de base (BCL), le même moteur d'exécution et les mêmes compilateurs. C'était en fait l'objectif de .NET 5 - qui succède aux offres .NET Core - lorsqu'il a fait ses débuts en novembre 2020. Mais des problèmes de développement exacerbés par la pandémie n'ont pas permis d'atteindre cet objectif.

En effet, tous les éléments prévus n'ont pas été intégrés à .NET 5 et ont été reportés jusqu'à l'arrivée de .NET 6 en novembre 2021 en tant que version LTS (Long Term Support). Mais même à ce moment-là, l'effort d'unification global de Microsoft était incomplet, car certains composants, tels que .NET Multi-platform App UI (.NET MAUI), n'ont pas respecté le calendrier. .NET MAUI a depuis atteint la disponibilité générale, et l'unification complète est désormais attendue pour novembre. Lors de la célébration des 20 ans de .NET en février dernier, Microsoft a réitéré son intention d'unifier tous les composants du framework à partir de .NET 7.

.NET 7 Release Candidate 1 a été testé avec Visual Studio 17.4 Preview 2. Il est recommandé d'utiliser les builds du canal preview si vous voulez essayer .NET 7 avec les produits de la famille Visual Studio. Sous macOS, il est recommandé d'utiliser la dernière version de Visual Studio 2022 pour Mac.

.NET Multi-platform App UI

NET Multi-platform App UI (MAUI) unifie les API Android, iOS, macOS et Windows en une seule API afin que vous puissiez écrire une application qui fonctionne nativement sur plusieurs plateformes. .NET MAUI permet d'offrir les meilleures expériences d'application conçues spécifiquement pour chaque plateforme (Android, iOS, macOS, Windows et Tizen) tout en vous permettant de créer une expérience de marque cohérente grâce à un style et des graphiques riches. Chaque plateforme est prête à l'emploi et se comporte comme elle le devrait, sans widgets ni style supplémentaires.

L'objectif principal de .NET MAUI est de permettre aux utilisateurs d'offrir la meilleure expérience d'application telle qu'elle a été conçue spécialement pour chaque plateforme (Android, iOS, macOS, Windows et Tizen grâce à la collaboration avec Samsung), tout en permettant de créer des expériences de marque cohérentes grâce à un style et des graphiques riches.

Dès le départ, chaque plateforme a l'apparence et le comportement qu'elle devrait avoir, sans qu'il soit nécessaire d'imiter des widgets ou des styles supplémentaires. Par exemple, .NET MAUI sur Windows est soutenu par WinUI 3, le premier composant d'interface utilisateur natif livré avec le SDK Windows App.

Dans le cadre de .NET 7, .NET MAUI fournit un projet unique qui gère le ciblage multiple des appareils et de leurs plateformes. L'expérience Visual Studio permettant de tester .NET MAUI avec .NET 7 sera disponible dans la prochaine version 17.4 Preview 2.1.

.NET MAUI fournit des API pour accéder aux services et aux fonctionnalités de chaque plateforme, tels que l'accéléromètre, les actions d'application, le système de fichiers, les notifications, et bien d'autres choses encore. Dans cet exemple, nous configurons des « actions d'application » qui ajoutent des options de menu à l'icône de l'application sur chaque plateforme :

Code :

Sélectionner tout

1
2
3
4
AppActions.SetAsync(
    new AppAction("current_info", "Check Current Weather", icon: "current_info"),
    new AppAction("add_location", "Add a Location", icon: "add_location")
);

Optimisé pour la vitesse

.NET MAUI est conçu pour les performances. Vous nous avez dit à quel point il est essentiel que vos applications démarrent le plus rapidement possible, notamment sur Android. Les contrôles d'interface utilisateur de .NET MAUI mettent en œuvre un modèle de gestionnaire-mappeur fin et découplé par rapport aux contrôles de la plate-forme native. Cela réduit le nombre de couches dans le rendu de l'interface utilisateur et simplifie la personnalisation des contrôles.

Les mises en page de .NET MAUI ont été conçues pour utiliser un modèle de gestionnaire cohérent qui optimise les boucles de mesure et d'arrangement pour accélérer le rendu et la mise à jour de l'interface utilisateur. Microsoft a également mis en place des dispositions pré-optimisées pour des scénarios spécifiques tels que HorizontalStackLayout et VerticalStackLayout en plus de StackLayout.

Avec pour objectif d'améliorer les performances au démarrage et de maintenir ou de réduire la taille des applications lors de la transition vers .NET 6. Microsoft obtient une amélioration de 34,9 % pour .NET MAUI et de 39,4 % pour .NET pour Android. Ces gains s'étendent également aux applications complexes ; l'application d'exemple .NET Podcast a démarré avec un temps de démarrage de 1299 ms, il est de 814,2 ms, soit une amélioration de 37,3 % depuis la preview 13.

Cloud Native

Les conteneurs sont devenus l'un des moyens les plus faciles de distribuer et d'exécuter un large éventail d'applications et de services dans le cloud. Le Runtime .NET a été renforcé pour les conteneurs il y a plusieurs années. Il est maintenant possible de créer des versions conteneurisées de vos applications avec seulement dotnet publish. Les images de conteneurs sont désormais un type de sortie pris en charge par le SDK .NET.

Le cloud native est un ensemble de bonnes pratiques pour créer des applications pour et dans le cloud afin de profiter de la résilience, de l'évolutivité, de l'efficacité et de la rapidité. .NET peut être utilisé pour créer des applications natives pour le cloud.

ARM64

.NET aide à créer des applications qui fonctionnent sur les appareils ARM. L'équipe .NET a continué à améliorer les performances de .NET 7 pour Arm64. L'architecture du jeu d'instructions ou l'ISA de x64 et d'Arm64 est différente pour chacune d'entre elles et cette différence est toujours mise en évidence sous la forme de performance. Bien que cette différence existe entre les deux plateformes, essayons de comprendre les performances de .NET sur les plateformes Arm64 par rapport à x64. L’objectif de Microsoft dans .NET 7 n'était pas seulement d'atteindre la parité de performance entre x64 et Arm64, mais aussi de fournir des indications claires sur ce qu’on doit attendre lorsqu’on déplace les applications .NET de x64 à Arm64.

Mise à l'échelle du pool de threads

Une dégradation significative des performances sur les machines à plus grand nombre de cœurs (32+) a été constaté. Par exemple, sur les machines Ampère, les performances ont chuté de près de 80 %. En d'autres termes, le nombre de requêtes/secondes (RPS) était plus élevé sur 28 cœurs que sur 80 cœurs. Le problème sous-jacent était la façon dont les threads utilisaient et interrogeaient la « file d'attente globale » partagée.

Lorsqu'un thread de travail avait besoin de plus de travail, il interrogeait la file d'attente globale pour voir s'il y avait plus de travail à faire. Sur les machines à fort nombre de cœurs, avec plus de threads impliqués, il y avait beaucoup de conflits lors de l'accès à la file d'attente globale. Plusieurs threads essayaient d'acquérir un verrou sur la file d'attente globale avant d'accéder à son contenu. Cela entraînait un blocage et donc une dégradation des performances.

Le problème de mise à l'échelle du pool de threads n'est pas seulement limité aux machines Arm64 mais est vrai pour toutes les machines qui ont un nombre de cœurs plus élevé. Ce problème a été corrigé dans dotnet/runtime#69386 et dotnet/aspnetcore#42237 comme le montre le graphique ci-dessous. Bien que cela montre des améliorations significatives, nous pouvons remarquer que la performance n'évolue pas de façon linéaire avec plus de cœurs de machine.

Mise à l'échelle du pool de threads

Une dégradation significative des performances sur les machines à plus grand nombre de cœurs (32+) a été constaté. Par exemple, sur les machines Ampère, les performances ont chuté de près de 80 %. En d'autres termes, le nombre de requêtes/secondes (RPS) était plus élevé sur 28 cœurs que sur 80 cœurs. Le problème sous-jacent était la façon dont les threads utilisaient et interrogeaient la « file d'attente globale » partagée.

Lorsqu'un thread de travail avait besoin de plus de travail, il interrogeait la file d'attente globale pour voir s'il y avait plus de travail à faire. Sur les machines à fort nombre de cœurs, avec plus de threads impliqués, il y avait beaucoup de conflits lors de l'accès à la file d'attente globale. Plusieurs threads essayaient d'acquérir un verrou sur la file d'attente globale avant d'accéder à son contenu. Cela entraînait un blocage et donc une dégradation des performances.

Le problème de mise à l'échelle du pool de threads n'est pas seulement limité aux machines Arm64 mais est vrai pour toutes les machines qui ont un nombre de cœurs plus élevé. Ce problème a été corrigé dans dotnet/runtime#69386 et dotnet/aspnetcore#42237 comme le montre le graphique ci-dessous. Bien que cela montre des améliorations significatives, nous pouvons remarquer que la performance n'évolue pas de façon linéaire avec plus de cœurs de machine.

Source : Microsoft

Et vous ?