Размер "кучи" поколения 0.NET

Спасибо, ребята, за вашу помощь.

Вот так, ситуация очень интересная. Я никогда не упоминал, что я храню эти 30 МБ объектов в массиве, размер которого составляет 100000. Сначала я выделяю этот массив, а затем заполняю его объектами. Поскольку этот массив больше 85 КБ, он сохраняется в куче больших объектов. Оказывается, что для сборки мусора для сбора объектов в этой куче необходимо запустить сборщик gen2, поэтому каждый раз, когда в куче больших объектов не хватает места, он запускает сборщик gen2, который снижает производительность. Вот простой пример, который будет постоянно называть коллекцию gen2. Вам нужно запустить его в режиме отладки (из-за оптимизации компилятора).

static void Main(string[] args)
{
     while (true)
     {
         byte[] objects = new byte[100000];
     }
}

Означает ли это, что когда мне нужен временный массив, размер которого превышает 85 КБ,

Размер разных поколений является деталью реализации, и я не знаю ни одного способа настроить его для приложений .NET. Если память мне не изменяет, поколение 0 и 1 совместно используют один сегмент, а в Win32 - 16 МБ, поэтому, если вы создадите много объектов, некоторые из них будут переведены в более высокие поколения, если на них все еще есть ссылки (так же, как ты опиши)

Я предполагаю, что идея ограничения размера 0 заключается в том, чтобы коллекция g0 была дешевой. Если поколение 0 может вырасти до любого размера, ваша общая производительность, скорее всего, пострадает.

РЕДАКТИРОВАТЬ: Я думаю, что книга Джеффри Рихтера имеет некоторые подробности об этом, так что вы можете проверить это.

РЕДАКТИРОВАТЬ 2: Рихтер заявляет (стр. 502-507), что начальный бюджет поколения 0 составляет 256 КБ, а первоначальный бюджет поколения 1 составляет 2 МБ. Тем не мение, это не размер поколения. Бюджеты корректируются по мере необходимости и будут увеличиваться и уменьшаться в зависимости от использования памяти приложением.

Профессиональная .NET Framework 2.0 Джо Даффи утверждает, что эфермальные поколения (т.е. поколения 0 и 1) разделяют один сегмент, который обычно составляет 16 МБ (стр. 117). Только поколению 2 разрешено расти по мере необходимости (я предполагаю, что LOH также может расти по мере необходимости, но это не ясно из текста).

Только поколению 2 разрешено расти по мере необходимости (я предполагаю, что LOH также может расти по мере необходимости, но это не ясно из текста).

Только поколению 2 разрешено расти по мере необходимости (я предполагаю, что LOH также может расти по мере необходимости, но это не ясно из текста).

Я не думаю, что есть какая-либо опция для установки этих значений в .NET GC.

На первый взгляд, похоже, что эта конкретная ситуация оправдывает необходимость иметь такие расширенные опции , но если это будет статическая опция , то она будет влиять на всю вашу жизнь. программа. Опция dynamic , которую вы могли бы установить во время выполнения, была бы идеальной.

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

Поскольку GC самонастраивается, gen (0) автоматически увеличивает размер, и объекты BIG рано или поздно будут собираться мусором.

Куча поколения 0 изначально имеет размер кеша вашего процессора. Это связано с тем, что небольшие временные объекты даже не нужно перемещать в основную память.

Are you sure you are no longer referencing these objects? The GC is very good at tuning itself to the needs of your application and would not promote objects to Generation 2 unless you had roots for those objects somewhere.

I think if you figure out where these roots are and ensure that you really are no longer referencing these objects anywhere then the GC will start freeing the memory for those objects and never promote them to Generation 1 let alone Generation 2. Also if you do this then the GC will detect that you need Generation 0 to be larger and will increase the size of the heap on your behalf.

+1 to Andrew. The GC is self-tuning it learns about the app's memory need patterns on the fly.
In your case, if the GC performs a collection of Gen 0 and finds that a lot of objects survived / not a lot of memory was reclaimed, the garbage collector will grow the Gen 0 budget/quota automatically.

Looking at GC Type members, there doesn't seem to be a way to programatically configure GC Generation budgets/size.

В первом поколении 0 может увеличиваться и уменьшаться, но это будет в будущем.когда процесс запускается, инициализированная управляемая куча имеет фиксированный размер в поколении 0 256 КБ (что означало Рихтера), потому что современные компьютеры имеют 256 и более памяти для ресурсов ЦП 2-го уровня. Второй. Андрей, ты прав. Когда какой-то объект настолько велик, он сразу переходит в gen2. Я могу предположить, что вы хотели уменьшить размер gen0, чтобы вызвать более часто вызываемый сборщик мусора, чтобы очистить неиспользуемое пространство и сделать ваше приложение легче. У меня такая же проблема на веб-сайте SilverLight, и я ищу решение. Я думаю, что, если код создает много объектов, у которых есть корни, и когда gen0 заполнен, CLR вызывает GC, который перемещает их в gen1, а затем, когда объектов становится больше, перемещает их в gen2. Допустим, все 3 поколения почти заполнены. Потом например вызвал GC. Что он будет делать. Просто очистить поколение0? Как с 1-м и 2-м. Я думаю, что решение сохранить светлую память заключается в следующем. Сначала создайте маленькие и много объектов вместо больших по размеру и меньшему количеству. Внутренняя привязка вторых объектов должна быть односторонней, а не хаотичной. Статические объекты, которые не создаются динамически, например, в соответствии с поступающими записями из базы данных, должны храниться в глобальных переменных и не создаваться повторно, когда код вычисляет их.