Grands tableaux et fragmentation LOH. Quelle est la convention acceptée?

Premièrement, le collecteur des ordures les collecte le loh, donc ne pas être immédiatement effrayé par sa présence. La LOH est collectée lorsque la génération 2 est collectée.

La différence est que le LOH ne soit pas compacté, ce qui signifie que si vous avez un objet dans une longue durée de vie, vous diviserez efficacement la LOH en deux sections - la zone avant et la zone après cet objet. . Si ce comportement continue de se produire, vous pourriez vous retrouver avec la situation où l'espace entre des objets à longue durée n'est pas suffisamment important pour les affectations ultérieures et .NET doit attribuer de plus en plus de mémoire afin de placer vos objets importants, c'est-à-dire le loh se fragmente.

Maintenant, après cela, le LOH peut réduire de taille si la zone à sa fin est totalement exempte d'objets en direct, le seul problème est donc si vous laissez des objets là-bas pendant une longue période (par exemple, la durée de l'application. ).

à partir de .NET 4.5.1, LOH pourrait être compacté, voir gcsettings.largeObjectHeapCompactionMode propriété.

stratégies pour éviter la fragmentation LOH sont les suivantes:

• Évitez de créer de gros objets qui traînent. Fondamentalement, cela signifie simplement que de grandes matrices ou des objets qui enveloppent de grandes matrices (telles que la mémoire Mémoire qui enveloppe une matrice d'octet), car rien d'autre n'est que grand (les composants d'objets complexes sont stockés séparément sur le tas, de manière rarement très grande). Agitez également pour les grands dictionnaires et les listes car ils utilisent un tableau en interne.
• Faites attention aux doubles tableaux - le seuil de ces entrants dans le Lhin est beaucoup, beaucoup plus petit - je ne me souviens pas de la figure exacte mais que c'est seulement quelques milliers.
• Si vous avez besoin d'une mémoire Mémoire, envisagez de faire une version punkée qui recule sur un certain nombre de baies plus petites plutôt que d'un grand tableau. Vous pouvez également effectuer une version personnalisée de l'IList et de la diatrictaire qui utilise des chunking pour éviter les trucs se retrouver dans le LOH en premier lieu.
• Évitez d'éviter de très longs appels de télécommandes, car la télécommande utilise une forte utilisation de Mémoramatreams pouvant fragmenter le loh pendant la longueur de l'appel.
• Faites attention à la chaîne interne - pour une raison quelconque, celles-ci sont stockées comme des pages de la LOH et peuvent provoquer une fragmentation sérieuse si votre application continue de rencontrer de nouvelles chaînes à stagiaire, c'est-à-dire éviter d'utiliser String.Intern à moins que l'ensemble des chaînes ne soit connue de Soyez fini et l'ensemble complet est rencontré tôt dans la vie de l'application. (Voir Ma question précédente .)
• Utilisez Fils de Strike pour voir ce qui utilise exactement la mémoire Loh. Encore une fois, voir Cette question pour plus de détails sur la façon de faire cela.
• Considérez Piscine de grandes tableaux .

  Edit: Le seuil de LOH pour les baies doubles semble être de 8k.