Quand la fragmentation adresse gérée en tas

Question

Je lisais un par Josh Smith, où il a utilisé un mécanisme de cache afin de « réduire la fragmentation du tas géré ». Sa mise en cache réduit le nombre d'objets de courte durée en cours de création au détriment de la vitesse d'exécution un peu plus lent.

Combien d'un problème est géré la fragmentation du tas dans un langage managé comme C #? Comment peut-on diagnostiquer si elle est un problème? Dans quelles situations auriez-vous besoin généralement pour y remédier?

Answer 1

  

Pas trop rapidement. Il est généralement très pas cher pour avoir des objets de courte durée. Pour un cache soit rentable, il faudrait être (très) nombreux candiadates et ils devraient vivre assez longtemps pour se rendre à la prochaine génération.

  

Comment peut-on diagnostiquer si elle est un problème?

Avec un profileur. Je ne suis pas si sûr l'auteur de l'article a fait.

  

Combien d'un problème est géré la fragmentation du tas dans un langage managé comme C #?

Pour autant que je sais qu'il est rare. .NET a un compactage éboueur qui empêche la plupart des formes de fragmentation. Il y a des problèmes avec le grand objet Heap parfois.

---

Edit:

Quand vous passez par les commentaires ci-dessous l'article que vous trouverez que quelqu'un mesuré et trouvé le cache d'être beaucoup plus lent que la création de nouveaux EventArgs chaque fois.

Conclusion: Mesure avant de commencer à optimiser. Ce ne fut pas une bonne idée / exemple.

Answer 2

Sauf si vous avez affaire à 10K + petits objets de courte durée par seconde, il ne devrait pas être un problème du tout sur un ordinateur moderne avec une quantité raisonnable de RAM.

Alors d'abord, vous devez exécuter le code dans tous les scénarios raisonnables et si elle est assez vite -. Ne vous inquiétez pas à ce sujet

Si vous n'êtes pas satisfait de la vitesse, vous voyez que le code parfois « selfs » ou simplement curieux, vous pouvez suivre diverses statistiques de mémoire .NET ( http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx ) dans l'application Analyseur de performances (vient dans le cadre de Windows ). Plus précisément, vous êtes intéressé par% Temps en GC.

Redgate ANTS profileur surveille également ces statistiques.

Answer 3

géré la fragmentation du tas est généralement en raison d'épingler des objets. Les objets s'épinglés lorsque le code managé passe le pointeur d'objet au code natif et l'objet ne peuvent pas être déplacés parce que la référence est transmise au code natif. Ceci est très fréquent quand il y a beaucoup d'activités d'E / S. Comme mentionné ci-dessus, il arrive souvent que dans LOH.

Voici un exemple de

Contrairement à d'autres réponses ici Je dis: oui, il faut prendre soin de la fragmentation! Il ne vaut pas seulement pour des tas gérés, mais à toutes les applications de manutention (au moins)

• de nombreux ressources "grandes" dans
• un modèle d'allocation lourde.

Étant donné que le LOB ne reçoit pas compacté, il - au fil du temps - le plus probablement se fragmentent dès que la taille et le nombre des objets dépassent une certaine valeur (qui se rapporte à l'ensemble heapsize max disponible). Dans le cas contraire, le seul moyen sûr est de limiter le nombre de références instantanément holded à ces objets. Un cache (pool) ne ferait qu'aider, si les objets mis en commun peuvent être réutilisés. Parfois, si ces ressources sont faites de tableaux de différentes F.E. longueur, ils pourraient ne pas être réutilisables facilement. Ainsi, la mise en commun ne peut pas aider beaucoup ici.

Comment détecter? Quand il en est grande pression sur le tas LOB. Comment savoir est? Utilisez la contre-performance .NET "Collection Count Gen 0 ... 2" en même temps. Si des objets trop grands sont attribués à partir du LOB, tous les compteurs évolueront de manière identique. Ce qui signifie, essentiellement toutes les collections sont cher génération 2 collections. Dans ce cas, il devrait y avoir quelque chose à faire.

En ce qui concerne les objets plus petits, je laisserais le GC faire tout le travail en général 0 collections et ne vous inquiétez pas.

Answer 4

Answer 5

Answer 6

Contrairement à d'autres réponses ici Je dis: oui, il faut prendre soin de la fragmentation! Il ne vaut pas seulement pour des tas gérés, mais à toutes les applications de manutention (au moins)

• de nombreux ressources "grandes" dans
• un modèle d'allocation lourde.

Étant donné que le LOB ne reçoit pas compacté, il - au fil du temps - le plus probablement se fragmentent dès que la taille et le nombre des objets dépassent une certaine valeur (qui se rapporte à l'ensemble heapsize max disponible). Dans le cas contraire, le seul moyen sûr est de limiter le nombre de références instantanément holded à ces objets. Un cache (pool) ne ferait qu'aider, si les objets mis en commun peuvent être réutilisés. Parfois, si ces ressources sont faites de tableaux de différentes F.E. longueur, ils pourraient ne pas être réutilisables facilement. Ainsi, la mise en commun ne peut pas aider beaucoup ici.

Comment détecter? Quand il en est grande pression sur le tas LOB. Comment savoir est? Utilisez la contre-performance .NET "Collection Count Gen 0 ... 2" en même temps. Si des objets trop grands sont attribués à partir du LOB, tous les compteurs évolueront de manière identique. Ce qui signifie, essentiellement toutes les collections sont cher génération 2 collections. Dans ce cas, il devrait y avoir quelque chose à faire.

En ce qui concerne les objets plus petits, je laisserais le GC faire tout le travail en général 0 collections et ne vous inquiétez pas.

Answer 7

Answer 8

Answer 9