Комментарии 4
MonoBehaviour должен быть несколько другого вида, чтобы избежать несколько аллокаций Vector3:
void Update()
{
var position = transform.localPosition; // тут новый
transform.localPosition = new Vector3(position.x, position.y, position.z + 1); // тут новый
}
Думаю каждый фрейм 200к объектов создавать выходит тяжеловато.
Вот более справедливый код:
private Vector3 point;
void Start() {
point = transform.localPosition;
}
void Update() {
point.z += 1;
transform.localPosition = point;
}
Добрый день, спасибо большое за рекомендацию. Я провел тест с MonoBeh еще раз и получил другие цифры и возросшую производительность. Стоит уточнить, что девайс не менялся.
Но дело не в аллокациях. Дело в том, что вы не вызываете каждый фрейм get localPosition.
Vector3 отрабатывается на стеке. Это почти бесплатно!
В ECS подходе все эти данные отработаются в одном Update Loop. Что даст еще больший прирост.
MonoBeh - аллокации в Update
MonoBeh - сохранение в локальную переменную
И вот в 2024м году все очень плохо с ситуацией в рамках ECS фреймворков для юнити
Лео сдох, максимально глупо - разраб решил наплодить 3 вариации своего фреймворка и вообще ушел в закрытые исходники - что не есть хорошо для комьюнити; в итоге для новых проектов его брать очень плохая идея (еще мемная ситуация с ним получается, такая же как в свое время с zenject'ом - фигава куча мертвых форков, эх, как же разрабы использующие юнити слюняво не умеют вести свои проекты)
ECS от самих юнитеков перемудрен чрезмерно и по всей день очень больно сетапится в проекте
Unity Actors - выглядит самым вкусным из всех, но плохо развит
Entitas - все еще перемудрен, и в итоге смысл его брать если есть ECS от самой юнити с такой же дичью в разработке
Остальные сдохли по непонятным причинам
Улучшаем ваш Unity проект. Гайд по ECS для MonoBehavior разработчиков