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

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

Хотя это так, но все же не выделение памяти 100%-но быстрее ее выделения. Смотри какие минимальные затраты создает выделение объектов:
1. Выделяемая память должна быть проинициализирована нулями. Это делается для больших блоков, потому не особо заметно на глаз, но все же время по любому тратится.
2. При создании объектов нужно обеспечить многопоточную безопасность. Даже если это всего один итрерлок, все равно это способно уменьшить производительность многопоточного приложения.
3. Рантайму нужно проинициализировать внутренние структуры объекта. Это нужно для GC и для того чтобы можно было получать инфотмацию о типах в рантайме.
4. При сборке мусора большое количество умерших объектов будет "разряжать" граф объектов, что приведет к увеличению промахов мимо кэша.
5. Распухание области отводимой под нулевое поколение GC приведет к более частым сборкам мусора.

Все это не так критично и при обычно этим можно пренебречь, но надо четко понимать, что не выделение памяти всегда быстрее ее выделения. Так что в критичных местах имеет смысл производить оптимизации вроде описанных в этой теме. Насколько я знаю в новом компиляторе Шарпа (из Розлина) во всю используются пулы объектов. Это делается именно в погоне за производительностью.