У меня проект на 80% состоит из плюсов например. Тем не менее нативизация бы чуть-чуть ускорила игру. Что касается разрабов кто на одних BP нативизация это даже спасение

А инлайн методов - оно что дает? :)

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

забываю Ответ тыкать

Это не ответ на мой вопрос. inline в C++98 значил скажем так совершенно не то, что значит двадцать лет спустя.

Дак вот, что дает inline specifier для методов?

То есть нынешний инлайн - это не инлайн?
Честно, не читал специально, я интуитивно подумал, что inline будет инлайнить метод. А это в свою очередь для производительности

инлайн не совсем инлайнит, да)

производительность тут вообще последнее дело

а для чего ещё инлайн, если не для производительности?

это если в кеш не влезло и если оптимизаций никаких не было, но всё равно сначала надо профилировать, а потом гипотезы строить

в узких случаях чтобы адрес переменной сохранить, но я сейчас мог борщануть и смысл обратный))

В точку) ну вот люблю я поизвращаться

инлайн теперь переменные есть, и они могут быть constexpr, и ещё всякие нюансы есть

имхо это самое близкое к реальному положению дел.

1. нативизация - искусственно созданный костыль костылей, для разгребания "совсем сложных" скоростей. Система-нашлепка, генерящая ужаснейший не-кеш-френдли код, имеющая к тому же свои отдельные баги. Теперь крашить может не только твой код, но и просто код нативизации.
2. поддрежка этой системы - весьма дорогая (постоянный источник багов). Даже сейчас нативизация не покрывает 100% случаев и имеет множество проблем.
3. ждем скриптовый язык. какое место в новой экосистеме для нативизации?
4. нативизация ставит крест на патчах
5. нативизация приводит к росту размера билда и потребления оперативной памяти
6. процесс сборки проектов с нативизацией - боль, содомия, страдания, увеличение цикла сборки иногда в разы и даже на порядки
7. игра "в редакторе" и игра "после нативизации" - формально две разных кодобазы — усложняет отладку
8. и главное - нативизация на общем уровне не решает проблем производительности. Проблемы быстродействия надо решать архитектурно и точечно, а не разливая "попробуем перевести в плюсы".

в любом случае сначала надо профилировать, а потом что-то делать

Ну я уж не буду из движка инлайны убирать и сравнивать профилировать. Но если в движке используется, то видимо прирост есть

могли просто оставить) из тех же соображений: "да ну его нафиг"; так и лежит теперь))

о, в движке много есть странных вещей и не очень объяснимых. Включая кучу легаси и работ разных "архитекторов", а также - знания тайных "важных мест".

спасиб, интересно