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

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

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

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

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

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