Комментарии 6
Осталось посмотреть количество аллокаций на каждый чих и больше никогда не пытаться пилить геймдев-код в enterprise стиле. Про статику во всех-всех вызовах апи вообще молчу - это за гранью добра и зла (TDD отдельно отпинают за углом за невозможность нормально писать тесты ко всему этому добру).
в апдейте каждой системы аллоцируются и удаляются Листы, страшно в профайлер вообще заглядывать))
ЗЫ. Был уверен что увижу твой комент первым :)
А если заменить алокацию на пул листов или других контейнеров?
пс: у нас сейчас backend java девелоперы(в том числе и я) пишут ui на unity3d. Сделали мы подходящий для себя фреймворк, но в в профайлер еще не заглядывали. Там будет тихий ужас, 100%, потому что на jvm обычно выделяют 100500 мб памяти, тюнят gc и только в самых критичных случаях начинают думать за другие оптимизации. Сейчас потихоньку собираем инфу как и что будем фиксить :)
Пулинг нужен, да. Основной посыл был - в выборках энтитей по условиям вообще не должно быть аллокаций в принципе. Как это сделано - достаточно посмотреть любой популярный фрейм, ссылки можно погуглить в соседнем посте https://habr.com/ru/post/665276/
а все что нужно было - взять любой хороший ЕЦС и дописать к нему небольшую прослойку для конвертации (или взять готовую, для ЛеоЕЦС такой конвертер есть, сторонний). Или подождать Entities 0.51, он в целом неплох.
Unity. Ленивый ECS