Комментарии 6
У меня мечта. Многие выделения, часто в рамках одного метода. Тот же боксинг. Вот если бы компилятор мог доказывать время жизни для таких обьектов, а clr поддерживала такие хитрые обьекты. То можно было бы и на стеке их создавать. Это бы ускорило все.
В репе .NET есть дизайн док на эту тему, но когда это будет реализовано неизвестно.
Читал у них про это где-то в issue гитхаба. Насколько я понял были эксперименты и они не оказали какого-то должного эффекта на производительность.
По быстрому поискал и нашёл такой комментарий:
We have spent quite a lot of time on automatically detecting good candidates for stack allocation in the JIT. https://github.com/dotnet/coreclr/issues/20253
is the uber issue for it, it has link to the design doc. The code with
the prototype is in master. It is disabled because of it did not show
enough benefits.
Еще немного и вы rust изобретёте ))
Вспомнил статью,-рекомендацию для dotNET в highload среде, стараться не отдавать, например, StringBuilder на съедение GC и использовать ObjectPool, т.к. повторное создание это расход ресурсов.
Любопытно, а какую производительность показал бы Unity построенный вместо плюсов на современном dotnet.
Сравнение сборщиков мусора в Unity и .NET