Analyse de l'empreinte mémoire physique de votre application à l'aide de Memory Profiler

Lorsqu'il s'agit de détecter efficacement les problèmes de mémoire et d'optimiser les performances, les informations affichées sur le profil de mémoire, ainsi que la précision de ces informations, sont essentielles. Nous investissons des efforts importants dans ce domaine. Dans deux blogs récents, les membres de mon équipe ont présenté Memory Profiler 1.0.0 et partagé cinq flux de travail clés pour diagnostiquer et examiner les problèmes liés à la mémoire dans votre jeu.

Bientôt, nous publierons Memory Profiler 1.1 (une version expérimentale est disponible dès maintenant), qui comprend des étiquettes et des descriptions mises à jour pour expliquer comment fonctionne la mémoire et comment l'empreinte mémoire de l'application est calculée.

L'empreinte mémoire étant un sujet brûlant dans nos conversations avec les développeurs, je suis ici pour répondre à vos questions fréquemment posées, en particulier pour couvrir ces trois sujets :

• Qu'est-ce que la mémoire résidente
• Comment l'empreinte mémoire de l'application est calculée
• Comment analyser l'empreinte mémoire

Examinons de plus près l’allocation de mémoire dans Unity. Lorsque le moteur alloue de la mémoire, il réserve d’abord plusieurs pages de mémoire dans l’espace d’adressage virtuel pouvant s’adapter à l’allocation demandée. Les pages sont les plus petites unités de gestion de la mémoire. L'espace d'adressage virtuel et le stockage physique sont chacun organisés en pages, et la taille de la page dépend de la plate-forme utilisée. Par exemple, sur les ordinateurs x86, la taille d’une page est de 4 Ko.

Une fois que le moteur a réservé suffisamment de pages, il demande au système d’exploitation (OS) de « valider » le stockage physique en mémoire. C’est pourquoi la mémoire allouée est souvent appelée « engagée ». Ensuite, le système d’exploitation enregistre que les pages disposent désormais d’un stockage physique attribué et qu’elles sont accessibles. La « mémoire totale engagée » signalée par votre application augmentera alors. Cependant, l’empreinte mémoire physique de votre application reste la même.

L'empreinte reste la même car, même si vous avez dédié votre région au stockage physique, la plupart des systèmes d'exploitation sont paresseux et économes, il n'y a donc pas d'attribution d'un emplacement de stockage physique spécifique. À titre d’exemple, disons que vous décidez d’écrire quelque chose dans la région engagée. Il n'y a pas encore de mémoire physique sous la région, donc y accéder entraînera une erreur de page. En réponse, le gestionnaire de mémoire du système d'exploitation allouera une page physique précédemment disponible afin de terminer votre opération. Étant donné que toutes les opérations sont effectuées avec une granularité de taille de page, les pages non consultées de la région resteront vides et sans mémoire physique attribuée. De même, la taille de la mémoire résidente de votre application augmentera de la taille totale de toutes les pages de mémoire physique allouées pour terminer votre opération.

Si une page n'a pas été consultée pendant un certain temps ou si la demande de mémoire physique est élevée, un système d'exploitation peut décharger certaines pages de votre région allouée vers une mémoire compressée ou un fichier d'échange de pages, selon ce qui est pris en charge sur votre plate-forme.

Dans ce cas, la mémoire allouée signalée par votre application restera la même, mais la taille de la mémoire résidente diminuera.

Comme vous l'avez peut-être déjà remarqué, si vous ne regardez que la mémoire allouée, vous risquez d'être induit en erreur quant à l'allocation qui consomme votre mémoire physique, ce qui peut vous amener à optimiser quelque chose qui n'est pas un problème. Non seulement cela vous fait perdre un temps précieux, mais vous ne constatez aucune différence dans les performances et la stabilité de votre application.

Dans l’ensemble, l’état de la mémoire de votre application peut être décrit par ce diagramme :

En résumé, voici comment l’empreinte mémoire est calculée :

Empreinte mémoire physique = Mémoire résidente de l'application + Pages de mémoire compressées de l'application

Dans Memory Profiler 1.1, les vues Résumé, Objets Unityet Toute la mémoire affichent non seulement la taille de la mémoire allouée , mais fournissent également des informations sur la mémoire résidente. Cependant, ces informations ne seront affichées que si l'instantané du Memory Profiler est réalisé avec Unity 2023.1 ou une version plus récente. Avec les instantanés plus anciens, vous verrez toujours l'interface utilisateur mise à jour et les vues de répartition, mais sans informations sur la mémoire résidente.

La vue Résumé fournit un aperçu général et une mesure essentielle : Nombre total de résidents sur l'appareil. Si votre application doit s'exécuter sur une plateforme avec une mémoire limitée, Total Resident on Device est essentiel pour examiner les avertissements de faible mémoire et les expulsions de mémoire insuffisante. En règle générale, vous ne devez pas dépasser 70 % de la mémoire physique totale disponible sur un appareil.

Pour une analyse détaillée, vous pouvez utiliser les vues Objets Unity et Toute la mémoire. Vous devrez sélectionner Résident sur l'appareil ou Alloué et résident sur l'appareil dans le menu déroulant et trier par taille de résident pour voir les objets qui contribuent le plus à la mémoire physique totale utilisée.

Lorsque vous analysez l'utilisation de la mémoire résidente, n'oubliez pas :

• La mémoire gérée sera majoritairement résidente. Mono Heap et Boehm Garbage Collector accèdent régulièrement aux objets et les rendent résidents.
• La mémoire graphique (estimée) est affichée comme estimée. Sur la plupart des plateformes, nous n'avons pas accès aux informations sur l'emplacement exact des ressources graphiques, nous estimons donc la taille en fonction des informations disponibles telles que la largeur, la hauteur, la profondeur, le format des pixels, etc. Cela signifie également que nous n'avons pas d'informations sur le statut de résidence des ressources graphiques. Pour des raisons de convivialité, tous les objets graphiques sont affichés uniquement dans le mode d'affichage Alloué.
• Ce qui n'est pas suivi est toute la mémoire signalée par le système d'exploitation comme étant allouée par l'application, mais qui manque d'informations solides sur la source de l'allocation. Il peut s'agir de plugins natifs, de bibliothèques de systèmes d'exploitation, de piles de threads, etc. Sur certaines plateformes, nous fournissons des informations supplémentaires sur la personne qui aurait pu allouer cette mémoire dans la répartition du groupe.

Lors de l'analyse de la mémoirenative , qui contient toutes les allocations non gérées par Unity utilisées par les objets, vous verrez l'élément Mémoire réservée . Il s'agit de la mémoire allouée par Unity Memory Manager mais non utilisée par aucun objet Unity lors de la capture. Voici quelques informations utiles :

• La mémoire réservée peut être résidente, ce qui signifie qu'il peut y avoir eu un objet qui a été récemment supprimé.
• Vous pouvez accéder à des informations supplémentaires sur la répartition réservée en accédant aux paramètres du profileur de mémoire et en activant la case à cocher « Afficher la répartition de la mémoire réservée ». Par défaut, cette option est désactivée, car la répartition réservée ne contient pas toujours suffisamment d'informations exploitables et nécessite une compréhension approfondie du fonctionnement de Unity Memory Manager.
• Vous pouvez en savoir plus sur Unity Memory Manager et les stratégies d’allocation dans la documentation de configuration des allocateurs .

Sur certaines plateformes, nous affichons des groupes supplémentaires spécifiques à la plateforme s'ils sont de taille importante, comme Android Runtime sur Android. Voici quelques notes sur Android Runtime :

• Sur certaines versions, Android Runtime a tendance à préallouer une quantité importante de mémoire mais à ne jamais l'utiliser. Dans ce cas, la mémoire allouée n'augmente pas l'empreinte mémoire de l'application et seule la partie résidente doit être prise en compte.
• Si la partie résidente d'Android Runtime occupe une quantité importante de l'empreinte mémoire de l'application, utilisez le profileur Android Studio pour analyser les allocations effectuées en Java.
• Bien qu'Android ne dispose pas de fichier d'échange ni de compression de mémoire par défaut, le noyau Linux permet aux applications de surcharger et d'allouer plus de mémoire que ce qui est physiquement disponible.
• Lors de la capture, assurez-vous de bien comprendre l'appareil que vous utilisez. Certains fournisseurs fournissent le noyau Android Linux avec des outils de compression de mémoire (zRAM) ou de fichiers d'échange de pages personnalisés par le fournisseur.

Nous espérons que cet aperçu de ce à quoi s'attendre dans Memory Profiler 1.1 (version expérimentale disponible maintenant) et l'exploration de divers sujets autour de l'empreinte mémoire ont été utiles.

Mon équipe et moi prévoyons de continuer à améliorer le Memory Profiler pour fournir des informations plus précises et ciblées, ainsi que pour vous avertir des situations potentielles de manque de mémoire et de leur proximité. Suivez l'évolution de notre feuille de route produit et dites-nous ce que vous en pensez.

Partagez vos commentaires avec nous dans les forums. Assurez-vous de surveiller les nouveaux blogs techniques d'autres développeurs Unity dans le cadre de la SérieTech from the Trenches.