Здравствуйте, master1, Вы писали:
KBH>>По-моему, нужно вызвать Dispose() компонента. M>можно. я так и делаю....
M> Form fm = new fmMidi(); M> //fm.MdiParent = this; M> fm.ShowDialog(); M> fm.Dispose(); M> fm = null;
M> GC.Collect(); M> GC.WaitForPendingFinalizers(); M> GC.Collect();
Dispose можно и не вызывать, если все ресурсы управляемые. Двойной вызов GC.Collect должен собрать весь мусор и освободить всю занятую память. Так что тут два варианта: либо у тебя где-то используются unmanaged resources, либо GC работает не правильно.
Здравствуйте, master1, Вы писали:
M>Как высвободить память занимаемую функцией new при захвате > 85000 байт?
Ну это будет "большой" объект с ним сборщик мусора работает отдельно. Память для них выделяется в отдельной куче и обект никогда не перемещается (т.е. куча не дефрагментируется). Сам объект сразу попадает во второе поколение, так что сборщик мусора может и не скоро до него добраться...
M>Что делать???
есть такой Performance Counter — Large Object Heap size, можешь посмотреть по нему освобождается ли память под большие объекты, если нет, то профайлером посмотреть кто его держит.
Здравствуйте, Mika Soukhov, Вы писали:
MS>б) Handle у Control будут удалены, даже если не был вызван метод Control.Dispose. Для этого есть финалайзеры тех классов, с которыми работает Control. Так что рано или поздно все удалится.
_ST>А можно более подробный комментарий насчет строк? Т.е. почему они плохо прибираются коллектором? (плодами любого семейства кидаться не буду
Нет, я не утверждал, что строки плохо собираются GC. Я внес уточнение в совершенно справедливое утверждение №2, о том, что "нужно избегать конструкций типа string a = b + c + d + e; особенно в цикле". Это правильно, этого нужно избегать. Но не потому, что строки плохо собираются GC, а потому, что с каждым присваиванием фактически выделется память под новую строку и просходит копирование. Т.е. страдает как производительность, так и растет кол-во используемой памяти (в т.ч. и той, которую надо будет потом сразу же заGCтить). Но это касается только строк. А вот если есть кучка локальных для метода мелких объектов -- счетчиков там, временных ссылок и т.п., то это, в принципе, неплохо.
Здравствуйте, mr_ST, Вы писали:
_ST>Да, но нужно понимать что это поздно может наступить настолько поздно... например при выходе из аппликации (это конечно клинический случай, но тем не менее)...
Для настольных-то приложений? Я вообще не думаю, что там так уж критична утечка памяти. Долго ли перезапустить прогу?
Как высвободить память занимаемую функцией new при захвате > 85000 байт?
GC.Commit() не помогает....
Например: Мы открывает окно с контролами (мапять выделяется), закрываем его (только часть памяти освобождается)
открываем еще раз — еще кусок памяти система забирает. и так далее.
В конце рабочего дня прграмма занимает около 250Mb!!! При этом страшно тормазит!
Что делать???
12.01.05 16:00: Перенесено модератором из 'Проектирование' — Хитрик Денис
Здравствуйте, KBH, Вы писали:
KBH>Здравствуйте, master1, Вы писали:
M>>Как высвободить память занимаемую функцией new при захвате > 85000 байт? M>>GC.Commit() не помогает....
KBH>По-моему, нужно вызвать Dispose() компонента.
можно. я так и делаю....
Form fm = new fmMidi();
//fm.MdiParent = this;
fm.ShowDialog();
fm.Dispose();
fm = null;
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, master1, Вы писали:
KBH>>>По-моему, нужно вызвать Dispose() компонента. M>>можно. я так и делаю....
M>> Form fm = new fmMidi(); M>> //fm.MdiParent = this; M>> fm.ShowDialog(); M>> fm.Dispose(); M>> fm = null;
M>> GC.Collect(); M>> GC.WaitForPendingFinalizers(); M>> GC.Collect();
M>Dispose можно и не вызывать, если все ресурсы управляемые. Двойной вызов GC.Collect должен собрать весь мусор и освободить всю занятую память. Так что тут два варианта: либо у тебя где-то используются unmanaged resources, либо GC работает не правильно.
Можно и не вызывать, всеравно толку нету
неуправляемых ресурсов я не использовал. А насчет GC... Ну как он может работать не правильно??
постоянно растет GC Handles, Gen 0 Collections,Gen 1 Collections,Gen 2 Collections
память высвобождается но не вся.
M>>Dispose можно и не вызывать, если все ресурсы управляемые. Двойной вызов GC.Collect должен собрать весь мусор и освободить всю занятую память. Так что тут два варианта: либо у тебя где-то используются unmanaged resources, либо GC работает не правильно.
M>Можно и не вызывать, всеравно толку нету M>неуправляемых ресурсов я не использовал. А насчет GC... Ну как он может работать не правильно??
M>постоянно растет GC Handles, Gen 0 Collections,Gen 1 Collections,Gen 2 Collections M>память высвобождается но не вся.
чуть не забыл! пастет назмер кучи объектов второго покаления! Gen 2 heap size
Здравствуйте, master1, Вы писали:
M>чуть не забыл! пастет назмер кучи объектов второго покаления! Gen 2 heap size
Ты что-то написал неверно. Хранишь мегабайты в статических хэштаблицах и так далее.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, master1, Вы писали:
M>>чуть не забыл! пастет назмер кучи объектов второго покаления! Gen 2 heap size P>Ты что-то написал неверно. Хранишь мегабайты в статических хэштаблицах и так далее.
не. я создал новый проект. там всего 2 окна,
второе окно используется только для размещение контролов и там выделяется кусок памяти
byte[] b = new byte[100000];
for (int i=0;i<100000;i++)
{
b[i]=233;
}
и собственно все!
Здравствуйте, Mishka, Вы писали: M>Dispose можно и не вызывать, если все ресурсы управляемые. Двойной вызов GC.Collect должен собрать весь мусор и освободить всю занятую память. Так что тут два варианта: либо у тебя где-то используются unmanaged resources, либо GC работает не правильно.
Лучше вызывать Dispose явно, это более эффективно чем дожидаться вызова финалайзера... Вызов GC.Collect, даже двойной, очистку _всего_ мусора не гарантирует, насколько я знаю. До GEN2 дело скорее всего не дойдет если в GEN0 освободится достаточно памяти...
Здравствуйте, master1, Вы писали:
M>>>чуть не забыл! пастет назмер кучи объектов второго покаления! Gen 2 heap size P>>Ты что-то написал неверно. Хранишь мегабайты в статических хэштаблицах и так далее. M>не. я создал новый проект. там всего 2 окна, M>второе окно используется только для размещение контролов и там выделяется кусок памяти M> byte[] b = new byte[100000]; M> for (int i=0;i<100000;i++) M> { M> b[i]=233; M> } M>и собственно все!
Попробовал твой тест. Gen 2 heap size доростает до 250Кб потом сбрасывается до 50Кб, Large Object Heap Size стоит как вкопаный на 16384 байтах... Подозреваю что проблемы в неосвобожденных Unmanaged ресурсах...
Как рекомендуют лучшие собаководы из Microsoft:
1. Не вызывайте GC.Collect никогда
2. Если все же нужно, то оправдано это только после того как закончили работу с большими объектами
иначе можно получить decrease perfomance...
Здравствуйте, master1, Вы писали:
M>Как высвободить память занимаемую функцией new при захвате > 85000 байт? M>GC.Commit() не помогает....
Никак объекты такого размера (если не изменяет память большие 20 Кил) помещаются в специальный хип. Этот хип создан по принципу malloc-а, т.е. на базе связанного списка свободных и занятых блоков. Память в нем не помпактися.
M>Например: Мы открывает окно с контролами (мапять выделяется), закрываем его (только часть памяти освобождается) M>открываем еще раз — еще кусок памяти система забирает. и так далее. M>В конце рабочего дня прграмма занимает около 250Mb!!! При этом страшно тормазит!
M>Что делать???
Ничего не делать. Если вы не теряете памяь, то эти блоки будут в последствии повторно использованя.
Если охота избежать вообще подобных заемов, то просто не занимайте таких окромных объемов за раз. Режте память на блоки. Ну, или создайте пул таких буферов и уравляйте им явно.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Spaider, Вы писали:
S>Здравствуйте, Mishka, Вы писали:
M>>Dispose можно и не вызывать, если все ресурсы управляемые.
S>Ша, медуза S>А хэндлы окон у нас уже стали управляемыми? А если на форме Control'ов до пупа?
А что, если я Dispose у контрола не вызову, так handle у меня навечно в памяти останется висеть?
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, Spaider, Вы писали:
S>>Здравствуйте, Mishka, Вы писали:
M>>>Dispose можно и не вызывать, если все ресурсы управляемые.
S>>Ша, медуза S>>А хэндлы окон у нас уже стали управляемыми? А если на форме Control'ов до пупа?
M>А что, если я Dispose у контрола не вызову, так handle у меня навечно в памяти останется висеть?
Вот чего было найдено на простораз тырнета, конкретно здесь:
When a control is disposed, it disposes all of its children. The only time you get automagic disposal of controls is when you do Application.Run(new Form()). (We like to call this showing the form modelessly). When the form gets WM_CLOSE message, it starts cleaning itself up while it can.
However if you do a Form.ShowDialog(), the form is NOT disposed. (We like to call this showing the form modally). This is because you may want to go in after the form has closed and look at the state of the child controls to determine the next action of your program.
If you add and remove controls from your form dynamically, you should call dispose on them – otherwise you’ll accumulate extra unwanted window handles in your process. Remember you only have to dispose the topmost control – so if you’re swapping in and out a panel – disposing the panel disposes it’s child controls.
S>Вот чего было найдено на простораз тырнета, конкретно здесь:
S>
S>When a control is disposed, it disposes all of its children. The only time you get automagic disposal of controls is when you do Application.Run(new Form()). (We like to call this showing the form modelessly). When the form gets WM_CLOSE message, it starts cleaning itself up while it can.
S>However if you do a Form.ShowDialog(), the form is NOT disposed. (We like to call this showing the form modally). This is because you may want to go in after the form has closed and look at the state of the child controls to determine the next action of your program.
S>If you add and remove controls from your form dynamically, you should call dispose on them – otherwise you’ll accumulate extra unwanted window handles in your process. Remember you only have to dispose the topmost control – so if you’re swapping in and out a panel – disposing the panel disposes it’s child controls.
Нда... вот вам и автоматическая сборка мусора от мелкософта, а то я то думал обрадоваться
--
То, что вы уникальны еще не значит, что от вас есть толк
Здравствуйте, Mishka, Вы писали:
M>>>Dispose можно и не вызывать, если все ресурсы управляемые. S>>Ша, медуза S>>А хэндлы окон у нас уже стали управляемыми? А если на форме Control'ов до пупа? M>А что, если я Dispose у контрола не вызову, так handle у меня навечно в памяти останется висеть?
Если не реализован финалайзер то останется. Но полагаться на финалайзер плохо. Дело в том что при очередном вызове коллектора объект не будет уничтожен он будет помещен в finalization queue и только при следующем вызове коллектора может быть уничтожен... Т.о. велика вероятность того что объкет попадет в более старшие поколения и соответственно может жить очень долго, что не есть гуд.
Здравствуйте, _Umka, Вы писали:
_U>Нда... вот вам и автоматическая сборка мусора от мелкософта, а то я то думал обрадоваться
Не надо обижаться
Ведь тут разговор про неуправляемые (unmanaged) ресурсы. Их-то нельзя "автоматом" собрать. Именно поэтому они и называются неуправляемыми.
Здравствуйте, _Umka, Вы писали:
S>>Вот чего было найдено на простораз тырнета, конкретно здесь: S>>
S>>When a control is disposed, it disposes all of its children. The only time you get automagic disposal of controls is when you do Application.Run(new Form()). (We like to call this showing the form modelessly). When the form gets WM_CLOSE message, it starts cleaning itself up while it can.
S>>However if you do a Form.ShowDialog(), the form is NOT disposed. (We like to call this showing the form modally). This is because you may want to go in after the form has closed and look at the state of the child controls to determine the next action of your program.
S>>If you add and remove controls from your form dynamically, you should call dispose on them – otherwise you’ll accumulate extra unwanted window handles in your process. Remember you only have to dispose the topmost control – so if you’re swapping in and out a panel – disposing the panel disposes it’s child controls.
_U>Нда... вот вам и автоматическая сборка мусора от мелкософта, а то я то думал обрадоваться
Автоматическая сборка работает прекрасно. Но:
1. Нужно всегда помнить об unamanged ресурсах которые коллектору неподвластны.
2. Даже если вызвали Dispose и не убили ссылку на объект он останется жить до тех пор пока жива ссылка. пример здесь
2. По возможности не плодить кучу временных объектов конструкциями типа string a = b + c + d + e; особенно в цикле (это повлияет только на производительность кода). Лучше пользоваться StringBuilder, string.Format etc.
3. По возможности не допускать попадания объектов в старшие поколения. (тоже производительность)
Здравствуйте, Spaider, Вы писали:
M>>А что, если я Dispose у контрола не вызову, так handle у меня навечно в памяти останется висеть?
S>Вот чего было найдено на простораз тырнета, конкретно здесь:
Нужно понимать, что:
а) GDI объекты и GDI+ объект — вещь совершенно разные. Если первые кончаются достаточно быстро, то вторые можно использовать, пока не кончится память.
б) Handle у Control будут удалены, даже если не был вызван метод Control.Dispose. Для этого есть финалайзеры тех классов, с которыми работает Control. Так что рано или поздно все удалится.
Здравствуйте, mr_ST, Вы писали:
_ST>2. По возможности не плодить кучу временных объектов конструкциями типа string a = b + c + d + e; особенно в цикле (это повлияет только на производительность кода). Лучше пользоваться StringBuilder, string.Format etc.
Позволю себе небольшой комментарий: следует писать не кучу временных объектов, а кучу строк.
Дело в том, что GC отлично справляется со сборкой большого количество недолго живущий объектов слабо связанных между собой (т.е. небольшое количество перекрестных ссылок). Т.е., грубо говоря, работая в CLR не нужно заморачиваться и раздумывать, делать 10 локальных переменных (если это не офигенный классищщще) или сократить количество до 8-7-6-5. Делайте больше и не заморачивайтесь, чтобы повысить читабельность кода. На производительность это повлияет несущественно.
Для желающих метать в меня плоды семейства пасленовых, отвечу сразу: "плохой танцор -- хороший папа", читай "любую технологию надо уметь использовать". Т.е. если в мозгах ветер -- никакая офигительно умная сборка мусора вам не поможет, ибо мусор находится между ушей, такой хрен соберешь.
Здравствуйте, Spaider, Вы писали:
S>Здравствуйте, mr_ST, Вы писали:
_ST>>2. По возможности не плодить кучу временных объектов конструкциями типа string a = b + c + d + e; особенно в цикле (это повлияет только на производительность кода). Лучше пользоваться StringBuilder, string.Format etc. S>Позволю себе небольшой комментарий: следует писать не кучу временных объектов, а кучу строк. S>Дело в том, что GC отлично справляется со сборкой большого количество недолго живущий объектов слабо связанных между собой (т.е. небольшое количество перекрестных ссылок). Т.е., грубо говоря, работая в CLR не нужно заморачиваться и раздумывать, делать 10 локальных переменных (если это не офигенный классищщще) или сократить количество до 8-7-6-5. Делайте больше и не заморачивайтесь, чтобы повысить читабельность кода. На производительность это повлияет несущественно.
А можно более подробный комментарий насчет строк? Т.е. почему они плохо прибираются коллектором? (плодами любого семейства кидаться не буду
S>Для желающих метать в меня плоды семейства пасленовых, отвечу сразу: "плохой танцор -- хороший папа", читай "любую технологию надо уметь использовать". Т.е. если в мозгах ветер -- никакая офигительно умная сборка мусора вам не поможет, ибо мусор находится между ушей, такой хрен соберешь.
Это бесспорно, как известно любую хорошую идею можно испоганить до полного непотребства.
Здравствуйте, mr_ST, Вы писали:
_ST>2. По возможности не плодить кучу временных объектов конструкциями типа string a = b + c + d + e; особенно в цикле (это повлияет только на производительность кода). Лучше пользоваться StringBuilder, string.Format etc.
Пример a = b + c + d + e некоректный. Посмотри, что на такой код генерит компилятор.
Здравствуйте, Mika Soukhov, Вы писали:
M>>>А что, если я Dispose у контрола не вызову, так handle у меня навечно в памяти останется висеть? S>>Вот чего было найдено на простораз тырнета, конкретно здесь: MS>Нужно понимать, что: MS>а) GDI объекты и GDI+ объект — вещь совершенно разные. Если первые кончаются достаточно быстро, то вторые можно использовать, пока не кончится память. MS>б) Handle у Control будут удалены, даже если не был вызван метод Control.Dispose. Для этого есть финалайзеры тех классов, с которыми работает Control. Так что рано или поздно все удалится.
Да, но нужно понимать что это поздно может наступить настолько поздно... например при выходе из аппликации (это конечно клинический случай, но тем не менее)...
Здравствуйте, Spaider, Вы писали:
_ST>>А можно более подробный комментарий насчет строк? Т.е. почему они плохо прибираются коллектором? (плодами любого семейства кидаться не буду S>Нет, я не утверждал, что строки плохо собираются GC. Я внес уточнение в совершенно справедливое утверждение №2, о том, что "нужно избегать конструкций типа string a = b + c + d + e; особенно в цикле". Это правильно, этого нужно избегать. Но не потому, что строки плохо собираются GC, а потому, что с каждым присваиванием фактически выделется память под новую строку и просходит копирование. Т.е. страдает как производительность, так и растет кол-во используемой памяти (в т.ч. и той, которую надо будет потом сразу же заGCтить). Но это касается только строк. А вот если есть кучка локальных для метода мелких объектов -- счетчиков там, временных ссылок и т.п., то это, в принципе, неплохо.
Допустим method2 выполняется очень долго и выделяет много памяти. Это может привести к неоднократному вызову коллектора, т.о. "толпа ссылок" может переехать на пмж в GEN2 откуда их вычистят очень нескоро... Желательно ненужнве ссылки зачищать перед вызовами подобных методов... Но это уже тюнинг
> > Допустим method2 выполняется очень долго и выделяет много памяти. Это > может привести к неоднократному вызову коллектора, т.о. "толпа ссылок" > может переехать на пмж в GEN2 откуда их вычистят очень нескоро... > Желательно ненужнве ссылки зачищать перед вызовами подобных методов... Но > это уже тюнинг
Если толпа ссылок не передается в method2, то ее успешно вычистят.
Posted via RSDN NNTP Server 1.9 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Lloyd, Вы писали:
_ST>>2. По возможности не плодить кучу временных объектов конструкциями типа string a = b + c + d + e; особенно в цикле (это повлияет только на производительность кода). Лучше пользоваться StringBuilder, string.Format etc. L>Пример a = b + c + d + e некоректный. Посмотри, что на такой код генерит компилятор.
Это проблемы отдельно взятого компилятора. Я как-то привык полагаться на свою голову а не на супер-пупер оптимизацию которая может быть, а может и не быть...
Здравствуйте, Mika Soukhov, Вы писали:
_ST>>Да, но нужно понимать что это поздно может наступить настолько поздно... например при выходе из аппликации (это конечно клинический случай, но тем не менее)... MS>Для настольных-то приложений? Я вообще не думаю, что там так уж критична утечка памяти. Долго ли перезапустить прогу?
Ну я сейчас не с совсем с десктопной прогой борюсь...
1. Рост памяти может быть очень немаленьким.
2. Подход "долго ли перезапустить прогу" не воспринимаю в принципе!
Здравствуйте, mr_ST, Вы писали:
_ST>Ну я сейчас не с совсем с десктопной прогой борюсь...
я не знаю с чем ты борешся. Все с чем то борются
_ST>1. Рост памяти может быть очень немаленьким.
Как и не очень большим
_ST>2. Подход "долго ли перезапустить прогу" не воспринимаю в принципе!
Я не предлагаю это делать. Просто я привел свой жизненный пример. Visual Studio после работы не выключаясь с неделю занимает порядка гигабайта памяти. Мне это ничуть не мешает, я просто перезагружаю ее и все.
>> >> Допустим method2 выполняется очень долго и выделяет много памяти. Это >> может привести к неоднократному вызову коллектора, т.о. "толпа ссылок" >> может переехать на пмж в GEN2 откуда их вычистят очень нескоро... >> Желательно ненужнве ссылки зачищать перед вызовами подобных методов... Но >> это уже тюнинг TK>Если толпа ссылок не передается в method2, то ее успешно вычистят.
Ошибся, в статье речь шла немного о другом. здесь
# re: Mid-life crisis 12/5/2003 10:55 AM Rico Mariani
You're absolutely right, if the JIT can statically determine that the variable is dead when the code is generated then there's no need null things out. However, what often happens in servers is that there are certain transaction state variables that are, for instance, on the "this" pointer which are still reachable. Those are the ones to null if you can.
For instance, suppose you got your input in XML format and you had a series of functions to extract what you need to do the query out of the XML, building up a SQL query string as you go. Just before you make the SQL query, it would be good to release all the stuff related to the XML that you can so that it can be collected. Objects like that are often fields accessable via your "this" pointer rather than local variables, so they are reachable until the object holding them goes away.
Other times there are helper collection classes that assist in the parsing and validation of the inputs. These objects also need to survive across several function calls (they are often accumulating results as process goes along), again these would seem live to the collector but perhaps they can be nulled or emptied.
# re: Mid-life crisis 12/5/2003 11:10 AM Rico Mariani
Let me alter your example just a tad, this is a stupid example using intermediate strings just to illustrate
class MyObj
{
private String s1;
private String s2;
private String s3;
public void DoSomethingFromInputs(String s)
{
...
s1 = AnElegantOperation(s);
...
}
public void ComputeInterimResults(String options)
{
...
s2 = SomethingEvenMoreElegant(s1, options);
...
}
public void ComputerFinalQuery(String database)
{
...
s3 = SQLFormatting(s2, database);
...
}
public String GetResults()
{
...
s1 = null; // this is what I'm talking about
s2 = null; // this is what I'm talking about
// this blocks a long time
String r = GetDataFromDatabase(s3)
...
return r;
}
}
MyObj o = new MyObj();
o.DoSomethingFromInputs(s);
o.ComputeInterimResults(options);
o.ComputeFinalQuery(databasename);
return o.GetResults();
(please forgive my syntax, I hope you can get the jist)
Здравствуйте, Mika Soukhov, Вы писали:
_ST>>1. Рост памяти может быть очень немаленьким. MS>Как и не очень большим
Обычно исходят из худшей ситуации. Полагаться на то что само устаканится моветон...
_ST>>2. Подход "долго ли перезапустить прогу" не воспринимаю в принципе! MS>Я не предлагаю это делать. Просто я привел свой жизненный пример. Visual Studio после работы не выключаясь с неделю занимает порядка гигабайта памяти. Мне это ничуть не мешает, я просто перезагружаю ее и все.
Угу, а если через час?
Здравствуйте, mr_ST, Вы писали:
_ST>>>2. Подход "долго ли перезапустить прогу" не воспринимаю в принципе! MS>>Я не предлагаю это делать. Просто я привел свой жизненный пример. Visual Studio после работы не выключаясь с неделю занимает порядка гигабайта памяти. Мне это ничуть не мешает, я просто перезагружаю ее и все. _ST>Угу, а если через час?
Ну что вы спорите. Вам ведь никто не гарантировал, что приложения под .NET будут работать правильно или вообще. Пока ещё есть возможность пишите на С++.
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, mr_ST, Вы писали:
_ST>>>>2. Подход "долго ли перезапустить прогу" не воспринимаю в принципе! MS>>>Я не предлагаю это делать. Просто я привел свой жизненный пример. Visual Studio после работы не выключаясь с неделю занимает порядка гигабайта памяти. Мне это ничуть не мешает, я просто перезагружаю ее и все. _ST>>Угу, а если через час?
M>Ну что вы спорите. Вам ведь никто не гарантировал, что приложения под .NET будут работать правильно или вообще. Пока ещё есть возможность пишите на С++.
