2010-09-01 1 views
5

Что означает функция точечного профайла dotTrace [Коллекция мусора]?

Что означает [сбор мусора] на этом рисунке? И «20 звонков»?

Я имею в виду, как я могу понять, почему GC так долго? Собиралось ли оно собирать много мелких предметов? Один большой? Любые подсказки относительно того, как оптимизировать это вообще?

Код в вопросе:

private void DeserializeFrom(SerializationInfo info) 
{ 
    Width = info.GetInt32("width"); 
    Height = info.GetInt32("height"); 
    var data = (List<byte>)info.GetValue("cells", typeof(List<byte>)); 
    cells = new Cell[physicalSize.Width, physicalSize.Height]; 
    int pos = 0; 
    for (int x = 0; x < physicalSize.Width; x++) 
    { 
     for (int y = 0; y < physicalSize.Height; y++) 
     { 
      cells[x, y] = new Cell(); 
      if (x < Width && y < Height) 
      { 
       cells[x, y].HasCar = data[pos]; 
       pos++; 
      } 
     } 
    } 
} 

Ничто не слишком фантазии. Я подозреваю, что виновником является большой объект List<byte>, но я думал, что сбор одного одного, большого объектов должен быть мгновенным (в отличие от сбора кучи мелких предметов).

ответ

1

Немного поздно на вечеринке, но если вы используете .Net, тогда вы используете управляемый код, что в основном означает, что среда выполнения .Net располагает вашими объектами соответственно, чтобы у вас не было утечек памяти, а не C или C++ ,

Сбор мусора всегда, когда время выполнения занимает некоторое время, чтобы управлять распределением и выпуском памяти для приложения. В этом случае это то, что происходит.

Пожалуйста, взгляните на этот фильтр, который можно использовать с doTrace (у меня есть версия 6), чтобы вы могли анализировать сборку мусора и определять, когда это может блокировать ваше выполнение. https://www.jetbrains.com/profiler/help/CLR_Activity.html

+0

Я понимаю, что это несколько месяцев, но я считаю, что стоит упомянуть, что вы абсолютно можете иметь утечку памяти в .net-коде. Статические события - очень распространенная причина этого. Если вы подписываетесь на статическое событие с переходным процессом и не можете отказаться от подписки на это событие, прежде чем выпустить все известные ссылки на переходный процесс, переходный процесс будет сохранен в результате ссылки из статического события; сборщик мусора никогда не соберет его. – Kelsie

+0

@kelsie вы правы, и я не выразил себя правильно. У вас нет утечек памяти в отношении того, как вы использовали программу с неуправляемым кодом, где было легко просто не освобождать объект и не иметь утечки памяти. Также, как вы правильно указываете, события - это один из способов, которыми вы можете хранить ссылку на объект, чтобы он не удалялся. – xmorera

+0

Другая возможность была в pre 4.5 с большой кучей объектов, когда ваше приложение было очень интенсивным в использовании массивов, которые были выделены в LOH, и учитывая, что до того, как вы не сможете сжать LOH, вы можете избавиться от исключений из памяти. – xmorera

Смежные вопросы