CLR

Présentation des améliorations des performances de .NET 4.5

Ashwin Kamath

 

Cet article présente la version préliminaire de Microsoft .NET Framework 4.5. Toutes les informations sur ce sujet peuvent faire l'objet de modifications.

Au sein de l'équipe Microsoft .NET Framework, nous avons toujours su qu'améliorer les performances est au moins aussi important pour les développeurs qu'ajouter de nouvelles fonctionnalités d'exécution et API bibliothèques. .NET Framework 4.5 a fait l'objet d'investissements importants en termes de performances qui profitent à tous les scénarios d'application. Par ailleurs, .NET 4.5 étant une mise à jour de .NET 4, vos applications .NET 4 peuvent également tirer parti de la plupart des améliorations de performances apportées aux fonctionnalités .NET 4 existantes.

Quand il s'agit de permettre aux développeurs de satisfaire les besoins en matière de performances applicatives, de temps de démarrage (voir msdn.microsoft.com/magazine/cc337892) et d'utilisation de la mémoire (voir msdn.microsoft.com/magazine/dd882521), le débit et la réactivité sont essentiels. Nous définissons les objectifs d'amélioration de ces mesures pour les différents scénarios d'application, nous mettons ensuite en place les modifications pour les atteindre, voire les dépasser. Dans cet article, je vous propose une présentation détaillée des principales améliorations en termes de performances qui ont été apportées à .NET Framework 4.5.

CLR

Dans cette version, nous avons mis l'accent sur : l'exploitation de plusieurs cœurs de processeur pour améliorer les performances, la réduction de la latence au niveau du Garbage Collector et l'optimisation de la qualité du code des images natives. Voici quelques-unes des fonctionnalités clés liées à l'amélioration des performances.

Juste-à-temps (JIT) pour le multicœur Nous surveillons en permanence les améliorations du matériel de bas niveau et travaillons avec les fournisseurs de puces pour obtenir les meilleures performances d'assistance matérielle. Notamment, une fois les puces multicœurs disponibles, nous les avons testées dans nos laboratoires de performances et nous avons apporté les modifications appropriées afin d'exploiter cette modification de matériel particulière. Toutefois, ces modifications n'ont profité qu'à très peu de clients.

À ce stade, presque chaque PC dispose d'au moins deux cœurs afin que les nouvelles fonctionnalités nécessitant plus d'un cœur soient utiles immédiatement et globalement. À un stade précoce du développement de .NET 4.5, nous avons décidé de déterminer si nous pouvions raisonnablement utiliser plusieurs cœurs de processeur pour partager la tâche de la compilation JIT (précisément comme partie intégrante du démarrage de l'application) et accélérer ainsi l'expérience globale. Dans le cadre de cette analyse, nous avons découvert que suffisamment d'applications gérées disposent d'un nombre minimal de méthodes compilées par JIT pour que l'investissement soit rentable.

La fonctionnalité consiste à utiliser les méthodes de compilation JIT susceptibles d'être exécutées sur un thread en arrière-plan, qui s'exécutera sur un autre cœur en parallèle s'il est situé sur un ordinateur à plusieurs cœurs. Dans le meilleur des cas, le deuxième cœur devance rapidement l'exécution principale de l'application. La plupart des méthodes sont donc compilées par JIT si nécessaire. Pour déterminer les méthodes à compiler, la fonctionnalité génère des données de profil qui assurent le suivi des méthodes exécutées, puis est ensuite guidée par ces données de profil lors d'une prochaine exécution. Cette exigence de génération de données de profil est le principal moyen vous permettant d'interagir avec cette fonctionnalité.

Avec un minimum de code supplémentaire, vous pouvez utiliser cette fonctionnalité du service d'exécution pour améliorer considérablement le temps de démarrage des applications clientes et des sites Web. En particulier, vous devez passer des appels simples à deux méthodes statiques sur la classe ProfileOptimization dans l'espace de noms System.Runtime. Pour plus d'informations, consultez la documentation MSDN. Notez que cette fonctionnalité est activée par défaut pour les applications ASP.NET 4.5 et Silverlight 5.

Images natives optimisées Nous avons activé dans plusieurs versions la précompilation du code pour les images natives via un outil de génération d'images natives (NGen). Les images natives consécutives entraînent généralement un démarrage des applications plus rapide qu'avec la compilation JIT. Dans cette version, nous avons introduit un outil supplémentaire appelé MPGO (Managed Profile Guided Optimization), qui optimise la disposition des images natives pour obtenir encore davantage de performances. Cet outil utilise une technologie d'optimisation guidée par les profils dont le concept est très similaire au JIT pour le multicœur décrit précédemment. Les données de profil pour l'application incluent un scénario représentatif ou un ensemble de scénarios, qui peuvent être utilisés pour réorganiser la disposition d'une image native afin que les méthodes ou les autres structures de données nécessaires au démarrage soient situées côte à côte de façon condensée au sein d'une partie de l'image native. Le temps de démarrage est ainsi raccourci et la plage de travail réduite (utilisation de la mémoire d'une application). Dans nos propres tests et expériences, nous remarquons en général que l'outil MPGO est avantageux pour les plus grandes applications gérées (par exemple, les grandes applications GUI interactives). Nous recommandons donc largement son utilisation pour ce type d'applications.

L'outil MPGO génère des données de profil pour une DLL du langage intermédiaire (IL) et ajoute le profil en tant que ressource de la DLL du IL. L'outil NGen est utilisé pour précompiler les DLL du IL après le profilage. Il effectue des optimisations supplémentaires en raison de la présence des données de profil. La figure 1 illustre le flux des processus.

Figure 1 Flux des processus avec l'outil MPGO

Opérateur d'allocation du tas des objets volumineux (LOH, Large Object Heap) De nombreux développeurs .NET ont demandé une solution au problème de fragmentation du LOH ou un moyen de forcer le compactage de ce dernier. Pour plus d'informations sur le fonctionnement du LOH, consultez la rubrique Les coulisses du CLR du numéro de juin 2008 de Maoni Stephens sur msdn.microsoft.com/magazine/cc534993. Pour résumer, tout objet dont la taille est de 85 000 octets ou plus est alloué sur le LOH. Actuellement, le LOH n'est pas compacté. Le compactage du LOH prend beaucoup de temps, car le garbage collector doit déplacer des objets volumineux. Par conséquent, il représente une solution coûteuse. Lorsque les objets sur le LOH sont collectés, ils laissent des espaces libres entre les objets qui survivent à la collecte, ce qui entraîne un problème de fragmentation.

Plus précisément, le CLR dresse une liste libre des objets morts qui peuvent être réutilisés plus tard pour répondre aux requêtes d'allocation des objets volumineux. Les objets morts adjacents sont transformés en un objet libre. Pour finir, un programme peut se retrouver dans une situation où ces fragments de mémoire libres entre les objets volumineux actifs ne sont pas suffisamment grands pour effectuer davantage d'allocations d'objets. Comme le compactage n'est pas une option, nous rencontrons rapidement des problèmes. Les applications ne répondent plus et des exceptions d'insuffisance de mémoire sont finalement générées.

Dans .NET 4.5, nous avons apporté des modifications pour optimiser l'utilisation des fragments de mémoire dans le LOH, notamment concernant notre façon de gérer la liste libre. Ces modifications s'appliquent au nettoyage de la mémoire (GC) pour les postes de travail et les serveurs. Veuillez noter que la limite fixée à 85 000 octets pour les objets LOH reste inchangée.              

GC d'arrière-plan de serveur Dans .NET 4.5, nous avons activé le GC d'arrière-plan pour le GC de poste de travail. Depuis, nous avons vu un plus grand nombre de machines avec des tailles de tas maximales allant de quelques gigaoctets à des dizaines de gigaoctets. Même un collecteur parallèle optimisé comme le nôtre peut mettre des secondes à collecter de tels tas volumineux, et bloquer pendant ce temps les threads d'application. Le GC d'arrière-plan de serveur assure la prise en charge des collectes simultanées pour notre collecteur de serveur. Il réduit les longues collectes bloquantes tout en maintenant un haut débit d'application.

Si vous utilisez le GC de serveur, vous n'avez rien à faire pour tirer parti de cette nouvelle fonctionnalité. Elle sera exécutée automatiquement. Les caractéristiques détaillées suivantes du GC d'arrière-plan sont les mêmes pour le GC de client et de serveur :

• Uniquement un GC complet (de la génération 2) peut être exécuté en arrière-plan.
• Un nettoyage de la mémoire d'arrière-plan n'effectue aucun compactage.
• Un GC de premier plan (GC de la génération 0/de la génération 1) peut être exécuté pendant le GC d'arrière-plan. Un GC du serveur est effectué sur les threads du GC du serveur dédiés.
• Le GC bloquant complet a également lieu sur les threads du GC du serveur dédié.

Programmation asynchrone

Un nouveau modèle de programmation asynchrone a été intégré à Visual Studio Async CTP et représente à présent une partie importante de .NET 4.5. Ces nouvelles fonctionnalités de langage dans .NET 4.5 permettent la création productive de code asynchrone. Deux nouveaux mots-clés de langage en C# et Visual Basic, « async » et « await », activent ce nouveau modèle. .NET 4.5 a également été mis à jour pour prendre en charge les applications asynchrones utilisant ces nouveaux mots-clés.

Le portail de programmation asynchrone Visual Studio sur MSDN (msdn.microsoft.com/vstudio/async) est une ressource très utile. Vous y trouverez des exemples, des livres blancs, des discussions sur les nouvelles fonctionnalités du langage et leur prise en charge.

Bibliothèques sur l'informatique parallèle

Un certain nombre d'améliorations ont été apportées aux bibliothèques sur l'informatique parallèle (PCL) dans .NET 4.5 afin d'optimiser les API.

Tâches allégées plus rapides Les classes System.Threading.Tasks.Task et Task<TResult> ont été optimisées afin d'utiliser moins de mémoire et de s'exécuter plus rapidement dans les scénarios clés. En particulier, les cas liés à la création de tâches et à la planification de suites ont connu des améliorations de leurs performances pouvant atteindre 60 %.

Davantage de requêtes PLINQ s'exécutant en parallèle S'il pense être plus nuisible (ralentissement), PLINQ revient à l'exécution séquentielle en parallélisant une requête. Ces décisions sont le fruit de suppositions réfléchies et ne sont pas toujours parfaites. Dans .NET 4.5, PLINQ reconnaîtra davantage de classes de requêtes qu'il pourra paralléliser avec succès.

Collectes simultanées plus rapides Un certain nombre d'ajustements ont été apportés à System.Collections.Concurrent.ConcurrentDictionary<TKey, TValue> pour gagner en rapidité dans certains scénarios.

Pour plus d'informations sur ces modifications, consultez le blog de l'équipe Parallel Computing Platform à l'adresse blogs.msdn.com/b/pfxteam.

ADO.NET

Prise en charge de la compression de ligne de bits avec la valeur Null Les données Null sont particulièrement courantes chez les clients qui exploitent la fonctionnalité des colonnes fragmentées de SQL Server 2008. Ces clients peuvent potentiellement générer des ensembles de résultats contenant un grand nombre de colonnes avec la valeur null. Pour ce scénario, la compression de ligne de bits avec la valeur Null a été introduite (jeton SQLNBCROW ou, simplement NBCROW). L'espace utilisé par les lignes des ensembles de résultats envoyés depuis le serveur avec un grand nombre de colonnes est ainsi réduit par compression de plusieurs colonnes de valeurs NULL en masque de bits. Ceci facilite de manière significative la compression des données du protocole de flux de données tabulaires (TDS) lorsque de nombreuses colonnes ayant la valeur null s'y trouvent.

Entity Framework

Requêtes LINQ compilées automatiquement Lorsque vous écrivez maintenant une requête LINQ to Entities, Entity Framework examine l'arborescence d'expression générée par le compilateur C#/Visual Basic et traduit (ou compile) le tout en SQL, comme illustré à la figure 2.

Figure 2 Requête LINQ to Entities traduite en SQL

La compilation de l'arborescence d'expression en SQL implique toutefois une certaine surcharge, en particulier pour les requêtes plus complexes. Dans les versions précédentes d'Entity Framework, si vous vouliez éviter d'avoir à subir des pertes de performances chaque fois d'une requête LINQ étaient exécutées, vous deviez utiliser la classe CompiledQuery.

Cette nouvelle version d'Entity Framework prend en charge une nouvelle fonctionnalité appelée Requêtes LINQ compilées automatiquement. À présent, chaque requête LINQ to Entities exécutée automatiquement est compilée et placée dans le cache de plan de requête d'Entity Framework. À chaque exécution supplémentaire de la requête, Entity Framework ira le chercher dans le cache de requête et vous n'aurez pas à relancer le processus de compilation complet. Vous trouverez des informations complémentaires sur ce sujet à bit.ly/iCaM2b.

Windows Communication Foundation et Windows Workflow Foundation

Les équipes de Windows Communication Foundation (WCF) et Windows Workflow Foundation (WF) ont également apporté à cette version un certain nombre d'améliorations de performances, dont les suivantes :

• Améliorations de l'évolutivité de l'activation TCP : les clients ont soulevé un problème d'activation TCP. Lorsque de nombreux utilisateurs simultanés ont envoyé des requêtes avec des reconnections constantes, le service de partage du port TCP ne s'est pas bien adapté. Ceci a été corrigé dans .NET 4.5.
• Prise en charge de la compression GZip intégrée pour WCF HTTP/TCP : avec cette nouvelle compression, nous prévoyons jusqu'à 5 fois le taux de compression.
• Recyclage de l'hôte lorsque l'utilisation de la mémoire est élevée pour WCF : lorsque l'utilisation de la mémoire est intensive (option configurable), nous utilisons la logique de l'ancienneté (dernier récemment utilisé) pour recycler les services WCF.
• Prise en charge de la diffusion en continu asynchrone HTTP pour WCF : nous avons implémenté cette fonctionnalité dans .NET 4.5 et obtenu le même débit que celui de la diffusion en continu asynchrone, mais avec une évolutivité nettement meilleure.
• Améliorations de la fragmentation de la génération 0 pour WCF TCP.
• Gestionnaire de tampons optimisé pour WCF pour les objets volumineux : pour les objets volumineux, une meilleure concentration des mémoires tampons a été mise en place afin d'éviter des coûts élevés du GC de la génération 2.
• Amélioration de la validation de WF avec la mise en cache des expressions : nous espérons jusqu'à trois fois plus d'améliorations pour un scénario de base qui charge WF et l'exécute.
• Suivi des événements de bout en bout de WCF/WF mis en place pour Windows (ETW) : bien qu'il ne s'agisse pas d'une fonctionnalité liée à l'amélioration des performances, elle aide les clients dans l'analyse de leurs performances.

Vous pouvez trouver plus d'informations sur le blog de l'équipe Workflow à l'adresse blogs.msdn.com/b/workflowteam et dans l'article de la MSDN Library à l'adresse bit.ly/n5VCtU.

ASP.NET

Les deux objectifs de performance clés de l'équipe ASP.NET pour .NET 4.5 consistaient à améliorer la densité de site (également définie comme « consommation de mémoire par site ») et le démarrage à froid des sites en cas d'hébergement partagé.

Dans les scénarios d'hébergement partagé, de nombreux sites partagent la même machine. Dans de tels environnements, le trafic est généralement faible. Les données fournies par certaines entreprises d'hébergement montrent que la requête par seconde est le plus souvent en dessous de 1 rps, avec des pics occasionnels de 2 rps ou plus. Ce qui signifie que de nombreux processus de travail vont probablement mourir s'ils sont inactifs depuis longtemps (20 minutes par défaut dans IIS 7 et versions ultérieures). Par conséquent, le temps de démarrage devient très important. Dans ASP.NET, il s'agit du temps que prend le site Web pour recevoir une requête et y répondre, au moment où le processus de travail a été arrêté par rapport au moment où le site Web a déjà été compilé.

Dans cette version, nous avons mis en place plusieurs fonctionnalités visant à améliorer le temps de démarrage pour les scénarios d'hébergement partagé. Les fonctionnalités utilisées sont les suivantes :

• Placement des assemblys du dossier Bin (partage des assemblys de type commun) : la fonctionnalité de clichés instantanés d'ASP.NET active les assemblys utilisés dans un domaine d'application à mettre à jour sans décharger cet AppDomain (nécessaire, car CTRL verrouille les assemblys utilisés). Cette opération est effectuée en copiant les assemblys d'application vers un emplacement distinct (un emplacement par défaut déterminé par le CLR ou un emplacement spécifié par l'utilisateur) et en chargeant les assemblys à partir de cet emplacement. L'assembly d'origine peut être alors mis à jour lorsque le cliché instantané est verrouillé. ASP.NET active cette fonctionnalité par défaut pour les assemblys du dossier Bin afin que les DLL puissent continuer à être mises à jour lorsqu'un site est opérationnel.
• ASP.NET reconnaît le dossier Bin d'un site Web comme dossier spécial des assemblys compilés (DLL) pour les contrôles, composants ou autre code ASP.NET personnalisés qui doivent être référencés dans une application ASP.NET et partagés entre diverses pages du site. Un assembly compilé dans le dossier Bin est automatiquement référencé partout dans l'application Web. ASP.NET détecte également la dernière version d'une DLL spécifique du dossier Bin à utiliser par le site Web. Les applications préconfigurées prévues pour être utilisées par les sites ASP.NET s'installent en général dans le dossier Bin plutôt que dans le dossier Global Assembly Cache.
• Les équipes ASP.NET et CLR ont remarqué que, lorsque plusieurs sites résident sur le même serveur et utilisent la même application, la plupart de ces DLL de clichés instantanés ont tendance à être identiques. Ces fichiers étant lus à partir du disque et chargés dans la mémoire, cela entraîne plusieurs chargements redondants qui augmentent le temps de démarrage et la consommation de la mémoire. Nous avons utilisé des liens symboliques pour le CLR à suivre et mis ensuite en place l'identification des fichiers communs, puis nous les avons placés dans un emplacement spécial (vers lequel les liens symboliques pointeront). ASP.NET configure automatiquement l'activation des clichés instantanés pour les DLL du dossier Bin. Les hébergeurs partagés peuvent à présent configurer leurs machines en fonction des instructions d'ASP.NET afin d'obtenir le maximum d'avantages en termes de performances.
• Processeurs pour le multicœur : pour obtenir des informations à ce sujet, consultez la section précédente « CLR ». L'équipe ASP.NET utilise la fonctionnalité de compilation JIT pour améliorer le temps de démarrage en répartissant la compilation JIT entre les cœurs de processeur. Ceci est activé par défaut dans ASP.NET, vous pouvez tirer ainsi parti de cette fonctionnalité sans travail supplémentaire. Vous pouvez la désactiver en utilisant le paramètre suivant du fichier web.config :

<configuration>
<!-- ... -->
<system.web>
<compilation profileGuidedOptimizations="None" />
<!-- ... -->

• Prélecture : la technologie de prélecture de Windows est très efficace pour la réduction des coûts de lecture du disque liés à la pagination au démarrage de l'application. La prélecture est à présent activée (mais pas par défaut) sur Windows Server également. Pour activer la prélecture pour l'hébergement Web de haute densité, exécutez l'ensemble de commandes suivant sur la ligne de commande :

sc config sysmain start=auto
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 2 /f
reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher" /v MaxPrefetchFiles /t REG_DWORD /d 8192 /f
net start sysmain

• Vous pouvez ensuite mettre à jour le fichier web.config pour l'utiliser dans ASP.NET :

<configuration>
<!-- ... -->
<system.web>
<compilation enablePrefetchOptimization
  ="true" />
<!-- ... -->

• Réglage du GC pour l'hébergement Web de haute densité : le GC peut influer sur la consommation de mémoire d'un site, mais il peut être réglé pour permettre de meilleures performances. Vous pouvez régler ou configurer le GC pour obtenir de meilleures performances du processeur (ralentissement de la fréquence de collecte) ou une consommation de mémoire réduite (c'est-à-dire, des collectes plus fréquentes pour libérer de la mémoire plus rapidement). Pour activer le réglage du GC, vous pouvez sélectionner le paramètre HighDensityWebHosting du fichier aspnet.config dans le dossier Windows\Microsoft\v4.0.30319 afin d'atteindre une consommation de mémoire plus faible (travail de processus) par site :

<configuration>
<!-- ... -->
<runtime>
<performanceScenario
  value="HighDensityWebHosting" />
  <!-- ... -->

Pour plus d'informations sur les améliorations en matière de performances d'ASP.NET, consultez le livre blanc relatif à la mise en route de la prochaine version d'ASP.NET à l'adresse bit.ly/A66I7R.

Commentaires demandés

La liste présentée ici n'est pas exhaustive. Dans le cadre de cet article, nous avons choisi d'omettre les autres modifications mineures liées à l'amélioration des performances et de nous limiter aux fonctionnalités majeures. Ceci mis à part, les équipes de performances .NET Framework travaillent également sur l'amélioration des performances spécifiques aux applications de style Metro pour Windows 8. Lorsque vous téléchargez et essayez .NET Framework 4.5 et la version bêta de Visual Studio 11 pour Windows 8, veuillez nous faire part de vos commentaires ou suggestions que nous prendrons en compte pour les prochaines versions.

Glossaire

Hébergement partagé : également appelé « hébergement Web partagé », l'hébergement Web de haute densité permet à des centaines (voire des milliers) de sites Web de fonctionner sur le même serveur. Grâce au partage des coûts matériels, chaque site peut être maintenu à moindre coût. Cette technique a largement ouvert la porte aux propriétaires de sites Web.

Démarrage à froid : le démarrage à froid correspond au temps de lancement nécessaire dans le cas où votre application n'était pas déjà présente en mémoire. Vous pouvez faire l'expérience d'un démarrage à froid lors du démarrage d'une application après un redémarrage du système. Pour les applications volumineuses, le démarrage à froid peut prendre plusieurs secondes, car toutes les pages requises (code, données statiques, registre, etc.) ne sont pas présentes dans la mémoire et des accès disque onéreux sont nécessaires pour mettre les pages en mémoire.

Démarrage à chaud : le démarrage à chaud correspond au temps de démarrage d'une application déjà présente en mémoire. Par exemple, si une application a été lancée quelques secondes plus tôt, il est probable que la plupart des pages soient déjà chargées dans la mémoire et que le système d'exploitation les réutilisera, en évitant ainsi des temps d'accès disque onéreux. C'est pourquoi une application démarre plus rapidement lorsque vous l'exécutez la deuxième fois (ou pourquoi une deuxième application .NET démarre plus rapidement que la première, car des parties de .NET sont déjà chargées dans la mémoire).

Génération d'images natives, ou NGen : reportez-vous au processus de précompilation des exécutables du langage intermédiaire (IL) dans le code machine avant l'exécution. Il en résulte deux avantages principaux en termes de performances. Le premier, il réduit le temps de démarrage des applications en évitant d'avoir à compiler du code au moment de l'exécution. Le deuxième, il améliore l'utilisation de la mémoire en permettant aux pages de codes d'être partagées entre plusieurs processus. Il existe également un outil, NGen.exe, qui crée des images natives et les installe dans le cache des images natives sur l'ordinateur local. Le service d'exécution charge les images natives lorsqu'elles sont disponibles.

Optimisation guidée par les profils : l'optimisation guidée par les profils a prouvé qu'elle améliore les temps de démarrage et d'exécution des applications natives et gérées. Windows fournit l'ensemble d'outils et l'infrastructure nécessaires pour effectuer une optimisation guidée par les profils pour les assemblys natifs, alors que le CLR fournit l'ensemble d'outils et l'infrastructure nécessaires pour effectuer une optimisation guidée par les profils pour les assemblys gérés (MPGO ou Managed Profile Guided Optimization). Ces technologies sont utilisées par de nombreuses équipes au sein de Microsoft pour améliorer les performances de leurs applications. Par exemple, le CTRL effectue une optimisation guidée par les profils pour les assemblys natifs (optimisation guidée par les profils en C++) et pour les assemblys gérés (à l'aide de la MPGO).

Garbage Collector : le service d'exécution .NET prend en charge la gestion automatique de la mémoire. Il suit chaque allocation de mémoire effectuée par le programme géré et appelle régulièrement un garbage collector qui recherche la mémoire non utilisée afin de la réutiliser pour de nouvelles allocations. Une optimisation importante effectuée par le garbage collector consiste à ne pas rechercher chaque fois dans tout le tas, mais plutôt à le partitionner en trois générations (génération 0, génération 1 et génération 2). Pour plus d'informations sur le garbage collector, consultez la rubrique Les coulisses du CLR du numéro de juin 2009 sur msdn.microsoft.com/magazine/dd882521.

Compactage : dans le cadre du nettoyage de la mémoire, lorsque le tas se trouve suffisamment fragmenté, le garbage collector le compacte en déplaçant les objets actifs proches les unes des autres. L'objectif principal du compactage du tas consiste à élargir les blocs de mémoire disponible dans lesquels allouer davantage d'objets.

Ashwin Kamath est responsable de programme dans l'équipe CLR de .NET et a supervisé les fonctionnalités liées aux performances et à la fiabilité pour .NET Framework 4.5. Il travaille actuellement sur les fonctionnalités de diagnostic pour la plate-forme de développement Windows Phone.

Je remercie les experts techniques suivants d'avoir relu cet article : Surupa Biswas, Eric Dettinger, Wenlong Dong, Layla Driscoll, Dave Hiniker, Piyush Joshi, Ashok Kamath, Richard Lander, Vance Morrison, Subramanian Ramaswamy, Jose Reyes, Danny Shih et Bill Wert.