1. Спорно. Одно дело, что мы кэшируем единожды при запуске, вместо получения компонента каждый апдейт, что хорошо, а другое в принципе заранее в редакторе кэшировать. Даже затрудняюсь представить себе пример, где это бы себя окупило и проблема была именно в этом.
Можно вообще с MonoBehaviour на DOTS перелезть, там вообще нет нужды получать компоненты, ибо дата-ориентированный код и всё работает в связке системами. Но тоже, извините, DOTS работает быстрее не из-за того, что там при запуске не получается какой-то там компонент.
2. Вот замена mathf функций собственными это частая практика имеющая смысл. Не только для аппроксимации. С другой стороны, например, mathematics под burst делает своё дело зачастую просто потрясающе. Там часть функционала прямо выражена хардварными SIMD инструкциями.
3. Читабельность кода часто бывает гораздо важнее "оптимизации", потому что хватает явно не критических мест где хоть заоптимизируйся, т.к. ботлнек в другом месте.
5. Агрессивный инлайнинг вещь, в общем, хорошая, если применяется с умом. Сюда же можно было бы тогда записать развертывание циклов и тому подобные практики. В узких местах вполне себе и помогает.
6. Не понял о чем речь. Что-что отбросить? Может кто-то разжевать, если не сложно? х)
1. Спорно. Одно дело, что мы кэшируем единожды при запуске, вместо получения компонента каждый апдейт, что хорошо, а другое в принципе заранее в редакторе кэшировать. Даже затрудняюсь представить себе пример, где это бы себя окупило и проблема была именно в этом.
Можно вообще с MonoBehaviour на DOTS перелезть, там вообще нет нужды получать компоненты, ибо дата-ориентированный код и всё работает в связке системами. Но тоже, извините, DOTS работает быстрее не из-за того, что там при запуске не получается какой-то там компонент.
2. Вот замена mathf функций собственными это частая практика имеющая смысл. Не только для аппроксимации. С другой стороны, например, mathematics под burst делает своё дело зачастую просто потрясающе. Там часть функционала прямо выражена хардварными SIMD инструкциями.
3. Читабельность кода часто бывает гораздо важнее "оптимизации", потому что хватает явно не критических мест где хоть заоптимизируйся, т.к. ботлнек в другом месте.
5. Агрессивный инлайнинг вещь, в общем, хорошая, если применяется с умом. Сюда же можно было бы тогда записать развертывание циклов и тому подобные практики. В узких местах вполне себе и помогает.
6. Не понял о чем речь. Что-что отбросить? Может кто-то разжевать, если не сложно? х)
7. Ну, умножение вместо деления это классика.