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

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

BDA>>>Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.

G>>А сейчас деталей мало? Ты можешь в любой момент отключить GC, можешь в любой момент инициировать сборку мусора, можешь получать оповещения о приближении сборки мусора. Что тебе еще надо?

BDA>Тут где-то лежит статья Ткачева с графиками, в которой он рассказывает, как находил точку, где GC начинает безнадежно просирать Win Heap. Не помню, переходит ли он к вопросу о скрытых параметрах, приводящих к этой картине или довольствуется констатацией. А я же говорю про конфигурирование этих параметров.

Вы забываете, что GC основан на эвристиках и хорошо работает в 95% случаев. Зная эти эверистики легко придумать пример, который попадет в оставшиеся 5% и просадит быстродействие.
В реальности для этих 5% случаев вполне достаточно текущего уровня "контроля" над поведением GC.


BDA>Проще говоря, если дев заранее знает, что будет работать с таким или сяким количеством объектов, GC не должен переаллоцировать память в указанных пределах. С одной стороны, возрастет скорость памятеемких приложений (в соответствии с тем графиком). С другой, простейшее приложение не будет отжирать виртуальную память. Беды в этом нет, виртуальная память — очень дешевый ресурс (это просто маркировка куска свопа), но дергать диск лишний раз не придется. Для оптимизации настроек на этапе разработки можно было бы использовать профайлер, гоняя апп с типичными данными.
Это к настройке и алгоритмам GC вообще никакого отношения не имеет. Делайте WorkingSet побольше и GC не будет переаллоцировать страницы.


BDA>Это отдельная тема (от темы последствий полного убирания GC), просто я тоже всегда считал, что если сделать GC конфигурируемым, это лучше решит те проблемы, ради решения которых предлагается отказаться от GC вообще.
Вернемся к вопросу, где в реальных приложениях, а не искусственных примерах, вам не хватает текущих возможностей конфигурации GC?