Высокий уровень уборки мусора Gen 1

Question

Я профилирую приложение (использующее VS 2010), которое плохо работает в производственной среде. Одна из рекомендаций, данных VS 2010:

Относительно высокий уровень уборки мусора 1-го поколения. Если по дизайн, большинство структур данных вашей программы выделены и сохраняется в течение длительного времени, это обычно не проблема. Тем не мение, если это поведение непреднамеренно, ваше приложение может прикреплять объекты. Если вы не уверены, вы можете собрать данные о распределении памяти .NET и информация о времени жизни объекта, чтобы понять структуру памяти распределение, которое использует ваше приложение.

Поиск в Google дает следующую ссылку => http://msdn.microsoft.com/en-us/library/ee815714.aspx. Есть ли какие-то очевидные вещи, которые я могу сделать, чтобы уменьшить эту проблему? Кажется, я здесь потерян.

Дважды щелкните сообщение в окне списка ошибок, чтобы перейти к Отметки Просмотр данных профилирования. Найдите .NET CLR Memory # of Gen 0 Коллекции и .NET CLR Memory # столбцов Gen 1 Коллекции. Определите, существуют ли определенные фазы выполнения программы, где сборка мусора происходит чаще. Сравните эти значения в столбец% Time в GC, чтобы увидеть, если шаблон управляемой памяти выделение ресурсов вызывает чрезмерные накладные расходы на управление памятью.

Чтобы понять, как приложение использует управляемую память, профиль его снова работает. Профиль распределения памяти .NET и запрос Измерения продолжительности жизни объекта.

Для получения информации о том, как улучшить производительность сборки мусора, см. Основы сборщика мусора и советы по производительности в Microsoft Веб-сайт. Для получения информации о накладных расходов автоматического мусора коллекцию, см. Обнаружена куча больших объектов.

Answer 1

Соответствующая строка есть:

Чтобы понять схему использования управляемой памяти приложением, снова профилируйте его, запустив профиль выделения памяти .NET и запросите измерения времени жизни объекта.

Вам необходимо понять, сколько объектов выделяется вашим приложением и когда, и как долго они живут. Вы, вероятно, размещаете сотни (или тысячи!) Крошечных объектов внутри цикла где-то, не задумываясь о последствиях восстановления этой памяти, когда ссылки выходят из области видимости.

http://msdn.microsoft.com/en-us/library/ms973837.aspx состояния:

Теперь, когда у нас есть базовая модель того, как все работает, давайте рассмотрим некоторые вещи, которые могут пойти не так, как следствие. Тот даст нам хорошее представление о том, каких вещей мы должны стараться избегать чтобы добиться максимальной производительности коллектора.

Слишком много выделений

Это действительно самая основная вещь, которая может пойти не так. Выделение нового память с сборщика мусора действительно довольно быстрая. Как вы видете на рисунке 2 выше все, что должно произойти, как правило, для указатель выделения для перемещения, чтобы создать пространство для вашего нового объекта на «выделенная» сторона - она ​​не становится намного быстрее, чем эта. Тем не мение, рано или поздно должен произойти сбор мусора и все равно лучше, чтобы это случилось позже, чем раньше. Так ты хочешь чтобы убедиться, что при создании новых объектов это действительно необходимо и уместно сделать это, хотя создание только одного быстро.

Это может звучать как очевидный совет, но на самом деле это удивительно легко забыть, что одна маленькая строчка кода, которую вы пишете, может вызвать много распределений. Например, предположим, вы пишете сравнение какая-то функция, и предположим, что ваши объекты имеют ключевые слова поле и что вы хотите, чтобы ваше сравнение было без учета регистра на ключевые слова в указанном порядке. Теперь в этом случае вы не можете просто сравнить вся строка ключевых слов, потому что первое ключевое слово может быть очень короткая. Было бы заманчиво использовать String.Split, чтобы сломать ключевое слово строка на куски, а затем сравнить каждый кусок по порядку, используя нормальное сравнение без учета регистра. Звучит отлично, правда?

Ну, как оказалось, делать это не очень хорошая идея. Вы видите, String.Split собирается создать массив строк, что означает один новый строковый объект для каждого ключевого слова, первоначально в ваших ключевых словах строка плюс еще один объект для массива. Хлоп! Если мы делаем это в некотором роде, это много сравнений и ваши Функция сравнения двух строк в настоящее время создает очень большое количество временные объекты. Внезапно сборщик мусора будет работаю очень усердно от вашего имени, и даже с самыми умными Схема сбора там просто много мусора для очистки. Лучше, чтобы написать функцию сравнения, которая не требует распределения в все.