Повысит ли это эффективность оператора или эффективность ГХ с течением времени, если мы будем всегда выделять только байты [1024] и использовать только необходимое пространство?
Может быть.Вам придется профилировать его и посмотреть.
То, как мы распределяем узлы синтаксического дерева внутри компилятора Roslyn, довольно интересно, и в конце концов я собираюсь написать в блоге об этом.А до тех пор уместным в вашем вопросе будет немного интересного.Наш шаблон распределения обычно включает в себя выделение «нижележащего» неизменяемого узла (который мы называем «зеленым» узлом) и изменяемого «фасада» узла, который обертывает его (который мы называем «красным» узлом).Как вы можете себе представить, мы часто выделяем их попарно: зеленый, красный, зеленый, красный, зеленый, красный.
Зеленые узлы постоянны и, следовательно, долговечны;фасады недолговечны, потому что они отбрасываются при каждом редактировании.Поэтому часто бывает так, что сборщик мусора имеет зеленый / дырочный / зеленый / дырочный / зеленый / дырочный, а затем зеленые узлы перемещаются вверх на поколение.
Мы всегда предполагали, что уменьшение размеров структур данных приведет квсегда улучшайте производительность GC.Меньшие структуры равняются меньшему количеству выделенной памяти, равны меньшему давлению сбора, равны меньшему количеству сборов, равны большей производительности, верно?Но благодаря профилированию мы обнаружили, что уменьшение красных узлов на меньше в этом сценарии на самом деле снижает производительность GC. Что-то особенное с размером отверстий каким-то странным образом влияет на ГХ ;не будучи экспертом по внутренним компонентам сборщика мусора, мне непонятно, почему это должно быть.
Так возможно ли, что изменение размера ваших распределений может каким-то непредвиденным образом повлиять на GC? Да, это возможно. Но, во-первых, это маловероятно , а во-вторых, невозможно узнать, находитесь ли вы в такой ситуации, пока вы на самом деле не попробуете это по-настоящему-мерные сценарии и тщательно измеряйте производительность GC .
И, конечно, вы не можете быть в курсе производительности GC.Roslyn делает так много небольших распределений, что крайне важно, чтобы мы настроили наше поведение, влияющее на сборщик мусора, но мы делаем безумное количество небольших распределений.Подавляющее большинство программ .NET не делают акцент на GC, как мы.Если вы находитесь в меньшинстве программ, которые подчеркивают ГК интересными способами, то нет никакого способа обойти это;вам придется профилировать и собирать эмпирические данные, как мы делаем в команде Roslyn.
Если вы не в том меньшинстве, то не беспокойтесь о производительности GC;у вас, вероятно, есть более серьезная проблема в другом месте, с которой вам следует иметь дело в первую очередь.