Выделяет ли объекты одинакового размера GC или "новую" производительность?

Ответ 1

Будет ли это улучшать работу оператора или эффективность GC в течение долгого времени, если мы всегда выделяем только байты [1024] и используем только необходимое пространство?

Может быть. Вам нужно будет профилировать его и посмотреть.

То, как мы выделяем узлы синтаксического дерева внутри компилятора Roslyn, довольно интересно, и я в конце концов собираюсь сделать сообщение в блоге об этом. До тех пор, соответствующий бит на ваш вопрос - это интересная мелочь. Наш шаблон распределения обычно включает в себя выделение "основного" неизменяемого node (который мы называем "зеленым" node) и "измененным" факетом node, который его обертывает (который мы называем "красным" node), Как вы можете себе представить, часто бывает, что мы в конечном итоге выделяем их парами: зеленый, красный, зеленый, красный, зеленый, красный.

Зеленые узлы устойчивы и поэтому долговечны; фасады недолговечны, потому что они отбрасываются при каждом редактировании. Поэтому часто бывает, что сборщик мусора имеет зеленый/дырочный/зеленый/отверстие/зеленый/отверстие, а затем зеленые узлы движутся на несколько поколений.

Наше предположение всегда заключалось в том, что сокращение структуры данных будет всегда улучшать производительность GC. Меньшие структуры равны меньшему распределению памяти, равному меньшему объему сбора, равно меньшему количеству коллекций, равному большей производительности, не так ли? Но через профилирование мы обнаружили, что сокращение красных узлов в этом сценарии фактически снижает производительность GC. Что-то о конкретном размере отверстий влияет на GC нечетным образом; не будучи экспертом по внутренности сборщика мусора, мне непрозрачно, почему это должно быть.

Итак, возможно ли, что изменение размера ваших ассигнований может повлиять на GC каким-то непредвиденным образом? Да, это возможно. Но, во-первых, это маловероятно, а во-вторых, невозможно знать, находитесь ли вы в этой ситуации, пока не попробуете в реальном времени, мировых сценариев и тщательно измерять производительность GC.

И, конечно же, вы не можете быть уверены в производительности GC. Рослин делает так много небольших ассигнований, что крайне важно, чтобы мы настраивали наше поведение, влияющее на GC, но мы делаем безумное количество небольших распределений. Подавляющее большинство программ .NET не подчеркивают GC так, как мы делаем. Если вы находитесь в меньшинстве программ, которые интересны GC по-интересному, тогда нет никакого способа обойти это; вам нужно будет профилировать и собирать эмпирические данные, как и в команде Roslyn.

Если вы не в этом меньшинстве, не беспокойтесь о производительности GC; у вас, вероятно, есть большая проблема в другом месте, с которой вы должны иметь дело сначала.

Ответ 2

new работает быстро, именно GC вызывает проблемы. Таким образом, это зависит от того, как долго ваши массивы живут.

Если они живут только в течение короткого времени, я не думаю, что будет улучшено выделение 1024-байтных массивов. Фактически это будет оказывать большее давление на GC из-за потерянного пространства и, вероятно, ухудшит производительность.

Если они живут в течение жизни вашего приложения, я бы рассмотрел выделение одного большого массива и использование его блоков для каждого небольшого массива. Вам нужно будет просмотреть это, чтобы узнать, помогает ли это.

Ответ 3

Не совсем. Для выделения или очистки массива байтов требуется только одна команда, независимо от ее размера. (Я говорю о вашем случае, есть исключения)

Вам не стоит беспокоиться о аспекте производительности сборки мусора, если вы не уверены, что это узкое место для вашего приложения (т.е. вы создаете множество ссылок со сложными отношениями и бросаете его вскоре после этого... И мусор коллекция заметна.)

Чтобы прочитать отличный рассказ о хорошо известном (и весьма полезном) сайте с проблемами производительности с .NET GC (в впечатляющем варианте использования), см. этот блог. http://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector;)

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

Ответ 4

Я также не думаю, что только выделение массивов в 1024 байт улучшит GC. Поскольку GC не является детерминированным, я также думаю, что это не будет вашей проблемой.

Вы можете влиять на GC, используя операторы using {} arround ваши массивы, чтобы освободить память (возможно) раньше.

Ответ 5

Я не думаю, что GC будет проблемой и/или узким местом.

Выделение объектов разных размеров и освобождение их в другой последовательности может привести к фрагментированной памяти кучи. Таким образом, это может пригодиться распределение объектов того же размера.

Если вы действительно много выделяете/освобождаете и действительно видите это как узкое место, попробуйте повторно использовать объекты с кешем локального объекта. Это может привести к увеличению производительности, особенно если они являются объектами только для данных, которые не реализуют много логики. Если объекты реализуют много логики и требуют сложной инициализации mor (RAII-шаблон), я бы отказался от повышения производительности для надежности программы...

HTH

Марио