3 pièce(s) jointe(s)
Microsoft propose une préversion de sa fonctionnalité Compilation hiérarchisée dans .NET Core 2.1
Microsoft propose une préversion de sa fonctionnalité Compilation hiérarchisée dans .NET Core 2.1,
pour tirer le meilleur parti du démarrage et de l'exécution d'une app
Compilation hiérarchisée, qu’est-ce que c’est ?
Noah Falk rappelle que depuis les débuts de .NET Framework, chaque méthode de votre code était généralement compilée une fois. Cependant, il y a des compromis à faire pour décider comment faire cette compilation qui va affecter les performances de votre application. Par exemple, le JIT pourrait effectuer une optimisation très agressive et obtenir des performances stables, mais l'optimisation du code n'est pas une mince affaire, votre application démarrant très lentement.
Alternativement, le JIT pourrait utiliser des algorithmes de compilation très simples qui s'exécutent rapidement, de sorte que votre application démarre rapidement, mais la qualité du code serait bien pire et le débit des applications en régime permanent en souffrirait. .NET a toujours essayé d'adopter une approche équilibrée qui ferait un travail raisonnable au démarrage et en régime permanent, mais l'utilisation d'une seule compilation implique un compromis.
C’est ici qu’intervient la compilation hiérarchisée : « La fonctionnalité de compilation hiérarchisée modifie le principe en permettant à .NET de disposer de plusieurs compilations pour la même méthode pouvant être remplacée à chaud lors de l'exécution. Cela sépare la prise de décision afin que nous puissions choisir une technique qui convient le mieux au démarrage, choisir une seconde technique qui soit la meilleure pour un état stable, puis fournir des performances exceptionnelles sur les deux ».
Dans .NET Core 2.1, voici ce que cette fonctionnalité vise à faire pour votre application si vous la choisissez :
- temps de démarrage de l'application plus rapide : lorsqu'une application démarre, elle attend un code MSIL pour JIT. La compilation à plusieurs niveaux demande au JIT de générer la compilation initiale très rapidement, en sacrifiant si nécessaire l’optimisation de la qualité du code. Par la suite, si la méthode est appelée fréquemment, un code optimisé est généré sur un thread d'arrière-plan et le code initial est remplacé pour préserver les performances de l'application ;
- des performances d'état plus rapides : pour une application .NET Core standard, la plupart du code d'infrastructure est chargé à partir d'images pré-compilées (ReadyToRun). Une stratégie qui a fait ses preuves pour le démarrage Cependant, les images pré-compilées ont des contraintes de contrôle de version et des contraintes d'instruction CPU qui empêchent certains types d'optimisation. Pour toute méthode de ces images qui appelle fréquemment la compilation hiérarchisée, le JIT doit créer un code optimisé sur un thread d'arrière-plan qui remplacera la version pré-compilée.
Plus de rapide, oui, mais de quel ordre de grandeur ?
Microsoft rappelle que l’une des raisons pour laquelle la fonctionnalité est publiée en préversion est d'avoir les retours des développeurs sur leurs différentes applications Cependant, l’entreprise a déjà eu l’opportunité de faire quelques tests qui vont faire office d’illustration
Falk avance que : « Bien que très dépendant du scénario, nous espérons que ces résultats sont typiques de ce que vous verrez sur des charges de travail similaires et que les résultats continueront à s'améliorer au fur et à mesure que la fonctionnalité évoluera. La base de référence est .NET Core 2.1 RTM s'exécutant dans une configuration par défaut et tous les nombres sont mis à l'échelle de sorte que la ligne de base mesure toujours 1.0. Dans ce premier groupe, nous avons quelques tests Tech Empower et Music Store, notre application ASP.NET fréquente »
« Bien que quelques-uns de nos tests ASP.NET en aient particulièrement bien profité (MvcPlaintext RPS avec plus de 60%), la compilation hiérarchisée n’est en aucun cas spécifique à ASP.NET. Voici quelques exemples d'applications de ligne de commande .NET Core que vous pourriez rencontrer dans le développement quotidien »
Concrètement donc, quel pourrait être le rendement de vos applications? Au lieu de se lancer dans une prévision, Microsoft vous propose plutôt quelques règles générales pour mesurer vous même le rendement :
- les améliorations au démarrage s’appliquent principalement à la réduction du temps de code managé. Vous pouvez utiliser des outils tels que PerfView pour déterminer le temps que votre application passe à faire cela. Au cours des essais de Microsoft, le temps passé à jitter diminuait souvent d’environ 35% ;
- les améliorations permanentes s'appliquent principalement aux applications liées au processeur où une partie du code à chaud provient des bibliothèques précompilées .NET ou ASP.NET. Les profileurs tels que PerfView peuvent vous aider à déterminer si votre application est dans cette catégorie.
Source : Microsoft
Et vous ?
:fleche: Qu'en pensez-vous ?
Voir aussi :
:fleche: Microsoft annonce la sortie de .NET Core 2.1, avec de nombreux ajouts et améliorations qui viennent enrichir cet environnement
:fleche:.NET Core 3.0 offrira un support du développement d'applications de bureau, mais sur Windows uniquement
:fleche: Microsoft annonce la disponibilité de .NET Core 2.1 RC1, cette version peut déjà être utilisée en production
:fleche: Microsoft annonce la sortie de la deuxième préversion de .NET Core 2.1, cette version est prête pour des tests plus larges
:fleche: Microsoft annonce la disponibilité de la première préversion de .NET Core 2.1 pour Windows, macOS et Linux
