Здравствуйте, 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 и не убили ссылку на объект он останется жить до тех пор пока жива ссылка. пример здесь

Автор: mr_ST
Дата: 12.01.05

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. Делайте больше и не заморачивайтесь, чтобы повысить читабельность кода. На производительность это повлияет несущественно.

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

Здравствуйте, Mika Soukhov, Вы писали:

MS>б) Handle у Control будут удалены, даже если не был вызван метод Control.Dispose. Для этого есть финалайзеры тех классов, с которыми работает Control. Так что рано или поздно все удалится.

Я так и думал. Пойду сниму у Spaider-а баллы...

Здравствуйте, 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 некоректный. Посмотри, что на такой код генерит компилятор.

Здравствуйте, mr_ST, Вы писали:


_ST>А можно более подробный комментарий насчет строк? Т.е. почему они плохо прибираются коллектором? (плодами любого семейства кидаться не буду

Нет, я не утверждал, что строки плохо собираются GC. Я внес уточнение в совершенно справедливое утверждение №2, о том, что "нужно избегать конструкций типа string a = b + c + d + e; особенно в цикле". Это правильно, этого нужно избегать. Но не потому, что строки плохо собираются GC, а потому, что с каждым присваиванием фактически выделется память под новую строку и просходит копирование. Т.е. страдает как производительность, так и растет кол-во используемой памяти (в т.ч. и той, которую надо будет потом сразу же заGCтить). Но это касается только строк. А вот если есть кучка локальных для метода мелких объектов -- счетчиков там, временных ссылок и т.п., то это, в принципе, неплохо.

Вот, в кратце и всё.

Здравствуйте, 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тить). Но это касается только строк. А вот если есть кучка локальных для метода мелких объектов -- счетчиков там, временных ссылок и т.п., то это, в принципе, неплохо.

void method1()
{
    // объявляем толпу ссылок
    method2();
}

Допустим method2 выполняется очень долго и выделяет много памяти. Это может привести к неоднократному вызову коллектора, т.о. "толпа ссылок" может переехать на пмж в GEN2 откуда их вычистят очень нескоро... Желательно ненужнве ссылки зачищать перед вызовами подобных методов... Но это уже тюнинг

Здравствуйте, mr_ST, Вы писали:

_ST>Да, но нужно понимать что это поздно может наступить настолько поздно... например при выходе из аппликации (это конечно клинический случай, но тем не менее)...

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

Hello, "mr_ST"

>

> void method1()
> {
> // объявляем толпу ссылок
> method2();
> }
>

>
> Допустим method2 выполняется очень долго и выделяет много памяти. Это
> может привести к неоднократному вызову коллектора, т.о. "толпа ссылок"
> может переехать на пмж в GEN2 откуда их вычистят очень нескоро...
> Желательно ненужнве ссылки зачищать перед вызовами подобных методов... Но
> это уже тюнинг

Если толпа ссылок не передается в method2, то ее успешно вычистят.

Здравствуйте, Lloyd, Вы писали:

_ST>>2. По возможности не плодить кучу временных объектов конструкциями типа string a = b + c + d + e; особенно в цикле (это повлияет только на производительность кода). Лучше пользоваться StringBuilder, string.Format etc.
L>Пример a = b + c + d + e некоректный. Посмотри, что на такой код генерит компилятор.
Это проблемы отдельно взятого компилятора. Я как-то привык полагаться на свою голову а не на супер-пупер оптимизацию которая может быть, а может и не быть...

P.S. Приведи пожалуйста более корректный пример.

Здравствуйте, Mika Soukhov, Вы писали:

_ST>>Да, но нужно понимать что это поздно может наступить настолько поздно... например при выходе из аппликации (это конечно клинический случай, но тем не менее)...
MS>Для настольных-то приложений? Я вообще не думаю, что там так уж критична утечка памяти. Долго ли перезапустить прогу?
Ну я сейчас не с совсем с десктопной прогой борюсь...

1. Рост памяти может быть очень немаленьким.
2. Подход "долго ли перезапустить прогу" не воспринимаю в принципе!

Здравствуйте, mr_ST, Вы писали:

_ST>Ну я сейчас не с совсем с десктопной прогой борюсь...

я не знаю с чем ты борешся. Все с чем то борются

_ST>1. Рост памяти может быть очень немаленьким.

Как и не очень большим

_ST>2. Подход "долго ли перезапустить прогу" не воспринимаю в принципе!

Я не предлагаю это делать. Просто я привел свой жизненный пример. Visual Studio после работы не выключаясь с неделю занимает порядка гигабайта памяти. Мне это ничуть не мешает, я просто перезагружаю ее и все.

Здравствуйте, TK, Вы писали:

TK>Hello, "mr_ST"

>>

>> void method1()
>> {
>> // объявляем толпу ссылок
>> method2();
>> }
>>

>>
>> Допустим 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 будут работать правильно или вообще. Пока ещё есть возможность пишите на С++.

Чтобы наплодить еще больше утечек памяти?