Microsoft annonce la première version candidate de .NET 7, testée avec Visual Studio 17.4 Preview 2


Microsoft a publié en aot .NET 7 Preview 7. L’entreprise a annoncé qu’il s’agit du dernier aperu de .NET 7 et que la prochaine version sera la première release candidate (RC). Cet aperu de .NET 7 a permis 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 apporte .NET 7, notamment en ce qui concerne la réflexion, le remplacement des piles (OSR), le temps de marrage, l’AOT natif, l’optimisation des boucles et de nombreux autres domaines.

Lorsque le développement de .NET 7 a débuté, Microsoft expliquait à la communauté que cette nouvelle version allait enfin unifier tous les composants disparates des outils de développement .NET, permettant aux développeurs de créer tous 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 exacerbs par la pandémie n’ont pas permis d’attendre cet objectif.

En effet, tous les éléments prévus n’ont pas été intégrés à .NET 5 et ont été signalé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 globale 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 à tester 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.

Interface utilisateur de l’application multiplateforme .NET

NET Multi-platform App UI (MAUI) unifie les API Android, iOS, macOS et Windows en une seule API afin que vous puissiez créer une application qui fonctionne nativement sur plusieurs plates-formes. .NET MAUI permet de proposer les meilleures expériences applicatives spécifiquement pour chaque plateforme (Android, iOS, macOS, Windows et Tizen) pour créer une expérience de marque cohérente grâce à un style riche et des graphismes 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 car elle est spécialement conçue pour chaque plate-forme (Android, iOS, macOS, Windows et Tizen grâce à la collaboration avec Samsung), le tout en permettant de créer des expériences de marque cohérentes grâce à un style et des richesses graphiques.

Dès le départ, chaque plateforme à l’apparence et au 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 supporté 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 fournit un ciblage multiple des appareils et de leurs plates-formes. L’expérience Visual Studio qui permet 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 fonctions de chaque plate-forme, tels que l’accéléromètre, les actions d’application, les systèmes de fichiers, les notifications et d’autres options. Dans cet exemple, nous configurons des actions d’application qui ajotent des options de menu l’icne de l’application sur chaque plateforme :

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")
);

Optimisme pour la vitesse

.NET MAUI est conçu pour la performance. 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. Il réduit le nombre de calques dans le rendu de l'interface utilisateur et simplifie la personnalisation des contrôles.

Les mises en page de .NET MAUI ont été conues pour utiliser un modèle de gestion 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 etc VerticalStackLayout en plus de StackLayout.

Avec pour objectif d'améliorer les performances au détriment 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 mariage de 1299 ms, il est de 814,2 ms, soit une amélioration de 37,3 % depuis la preview 13.

Nuage natif

Les conteneurs sont devenus l'un des moyens les plus simples de distribution et d'exécution d'une large gamme d'applications et de services dans le cloud. Le Runtime .NET et renforc pour les conteneurs il y a plusieurs années. Il est maintenant possible de créer des versions conteniérisées de vos applications avec seulement dotnet publier. 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 la volatilité, 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 améliore en continu 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'attendre la parité de performance entre x64 et Arm64, mais aussi de fournisseur 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 fils

Une dégradation significative des performances sur les machines plus grand nombre de curs (32+) au 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 curs que sur 80 curs. Le problème sous-jacent était la façon dont les threads utilisaient et interrogeaient le fichier d'attente global partagé.

Lors d'un fil de travail avait besoin de plus de travail, il interrogeait le fichier d'attente globale pour voir s'il y avait plus de travail faire. Sur les machines fort nombre de curs, avec plus de threads implicites, il y avait beaucoup de conflits lors de l'accès au fichier d'attente globale. Plusieurs fils essayaient d'acquérir un verrou sur le fichier d'attente globale avant d'accéder à son contenu. Cela entrenait 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 curs plus lev. Ce problème est 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'est pas de façon linéaire avec plus de curs de machine.

Mise l'échelle du pool de fils

Une dégradation significative des performances sur les machines plus grand nombre de curs (32+) au 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 curs que sur 80 curs. Le problème sous-jacent était la façon dont les threads utilisaient et interrogeaient le fichier d'attente global partagé.

Lors d'un fil de travail avait besoin de plus de travail, il interrogeait le fichier d'attente globale pour voir s'il y avait plus de travail faire. Sur les machines fort nombre de curs, avec plus de threads implicites, il y avait beaucoup de conflits lors de l'accès au fichier d'attente globale. Plusieurs fils essayaient d'acquérir un verrou sur le fichier d'attente globale avant d'accéder à son contenu. Cela entrenait 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 curs plus lev. Ce problème est 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'est pas de façon linéaire avec plus de curs de machine.

La source: Microsoft

Qu'en pensez-vous?

Quelle est votre opinion sur le sujet ?

Voir également:

Microsoft annonce la disponibilité de .NET 6 Preview 4 qui apporte l'expérience Hot Reload, Visual Studio et aux outils de ligne commande

Google Chrome et Microsoft Edge prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités

Visual Studio 2022 Preview 4 est disponible et s'accompagne d'améliorations de la productivité personnelle et de l'équipement, du chargement à chaud dans ASP.NET Core et de la gestion des thèmes

Red Hat annonce un RHEL sans frais pour les petits environnements de production, notamment pour les charges de travail de production avec jusqu'à 16 serveurs de production

Leave a Comment