Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Общие вопросы по .NET и C# > Как отключить Garbage Collector


Автор: Djuffin 12.10.2006, 20:59
Существует ли какой-нибудь способ на время отключить сборку мусора ? 

В Ruby это делается так
Код

GC.disable()


В C# такой возможности кажется нет. Но возможно существую какие то обходные пути.

Автор: Exception 12.10.2006, 23:56
Зачем? Нет, нельзя.

Автор: mr.DUDA 13.10.2006, 08:51
Можно сделать это для конкретного объекта, метод GC.SuppressFinalize.

Автор: Prehistorik 13.10.2006, 08:59
А зачем это надо?!

Автор: Djuffin 13.10.2006, 09:10
2mr.DUDA:
GC.SuppressFinalize - просто отменяет необходимость вызывать Finilize() для какого-то конкретного объекта. Но от этого GC только быстрее его съест.

2Exception: 
Ну например:
Я выполняю действие которое выделяет и освобождает большое количество объектов. (Компиляция исходного кода из одного файла)
На протяжении этого действия сборка может пройти несколько раз. Мне кажется с точки зрения производительности было бы логично отключить ее на время выполнения этого действия, а потом за ОДИН раз сразу убрать весь мусор. Временный перерасход памяти в данном случае не критичен.

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

Я понимаю что эти сценарии не совсем однозначны. Но тем не менее  я не вижу причин по которым в .NET отсутствует такая возможность.
Вариант что авторы боялись что-то люди быдут часто стрелять себе в ногу не кактит, тогда бы они не предоставили доступа к unmanaged памяти через class Marshal.

Автор: -ser- 15.10.2006, 13:18
Цитата(Djuffin @  12.10.2006,  20:59 Найти цитируемый пост)
Существует ли какой-нибудь способ на время отключить сборку мусора ? 

отключить сборку мусора как таковой процесс, насколько мне известно, нельзя и это очень правильно.

Цитата(Djuffin @  13.10.2006,  09:10 Найти цитируемый пост)
Я выполняю сложный алгоритм, и я точно знаю что не освобождаю ссылок на объекты.  Мусора просто нет.  Тем не менее не исключина возможность того что GC будет запускаться 

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

и последнее, IMHO, если размер размещаемой памяти не меняется и ссылки не освобождаются (предположим такую утопию), то и GC запускаться не будет.

Автор: Djuffin 15.10.2006, 19:13
Цитата(-ser- @  15.10.2006,  13:18 Найти цитируемый пост)
 нельзя и это очень правильно.

Почему ты так считаешь?
Я не предлагаю часто пользоваться этой возможностью, но не вижу причин для полного ее исключения. 
Marshal - тоже не часто используют, но он есть! И это хорошо.

Цитата(-ser- @  15.10.2006,  13:18 Найти цитируемый пост)
ты наверно хотел сказать, что также и не размещаешь память под объекты, в противном случае процесс GC нужен.

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



Автор: Naum 16.10.2006, 14:47
Сильно не ругайте. Может быть скажу глупость, потому что никогда с этим не работал, а читать начал только сегодня. Заодно и узнаю, правильно я понял.
Так вот, как я понял, GC не будет подсчитывать ссылки на объект пока у того не закончиться время жизни. Получается если у объекта установить большое время жизни, то GC будет работать быстрее. 
Не так ли?

Автор: Djuffin 16.10.2006, 16:55
Цитата(Naum @  16.10.2006,  14:47 Найти цитируемый пост)
Так вот, как я понял, GC не будет подсчитывать ссылки на объект пока у того не закончиться время жизни. Получается если у объекта установить большое время жизни, то GC будет работать быстрее. 

Ты что-то путаешь.
Время жизни объекта - это просто время на протяжении которого он существует. Оно зависит от существования ссылок на него и от расторопности сборщика мусора. Это НЕ число которое ты можешь выставить программно. Это просто ВРЕМЯ ЖИЗНИ. (Совсем как у людей smile)

Автор: Exception 16.10.2006, 17:22
Время жизни объекта есть время, пока его значение отлично от null smile .

Автор: Naum 16.10.2006, 17:24
А тогда к чему термин "аренда времени жизни" и интерфейс ISponsor?

Добавлено @ 17:28 
Упс. smile  Кажись я вообще не про то.  smile  smile

Добавлено @ 17:31 
Цитата(Djuffin @  16.10.2006,  17:55 Найти цитируемый пост)
Ты что-то путаешь.


Прикольно, когда не знаешь, еще и путаешь.  smile 

З.Ы. Это я про себя.

Автор: arilou 17.10.2006, 16:46
Цитата(Djuffin @  13.10.2006,  09:10 Найти цитируемый пост)
2mr.DUDA:
GC.SuppressFinalize - просто отменяет необходимость вызывать Finilize() для какого-то конкретного объекта. Но от этого GC только быстрее его съест.

Ага, именно так. Это нужно для классов, реализующих IDisposable, чтобы не вызывать финалайзер, если уже вызывали Dispose.

Цитата(Djuffin @  15.10.2006,  19:13 Найти цитируемый пост)
Я готов мериться со временной "утечкой". 

А если память кончится?

Автор: Djuffin 17.10.2006, 17:10
Цитата(arilou @  17.10.2006,  16:46 Найти цитируемый пост)
А если память кончится?

Код

catch (OutOfMemoryException E)


Но я думаю этого не случиться. smile

Автор: maxim1000 17.10.2006, 18:01
Цитата(Djuffin @  15.10.2006,  18:13 Найти цитируемый пост)
Нет я выделяю память, но меня устраевает интенсивный рост размера кучи. Я готов мериться со временной "утечкой".


Цитата(Djuffin @  16.10.2006,  15:55 Найти цитируемый пост)
Время жизни объекта - это просто время на протяжении которого он существует. Оно зависит от существования ссылок на него и от расторопности сборщика мусора.


ну тогда решение такое: сохранять ссылки на все создаваемые объекты где-нибудь в одном контейнере и убивать его после отработки алгоритма  smile 

Автор: Djuffin 17.10.2006, 18:05
Цитата(maxim1000 @  17.10.2006,  18:01 Найти цитируемый пост)
ну тогда решение такое: сохранять ссылки на все создаваемые объекты где-нибудь в одном контейнере и убивать его после отработки алгоритма    

Сборшик мусора всеравно (даже гораздо чаще!) будет анализировать граф объектов в тщетных попытках найти мусор. => Цель не достигнута.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)