Clamp, Любой код требует оптимизации, даже который учит этому)

После истории с "оптимизацией" цикла рассматривал статью, как список вредных советов.
В блоках кода, которые требовательны к производительности для целочисленных рассчетов всегда, всегда применяйте тип int или dword. Это универсальные типы, для х86-64 платформ, ибо все команды оперируют именно ими или удвоенными аналогами в случае 64битных систем. В следствии чего не происходит ненужных преобразований.
Со строками ваще фейл, команда string.concat быстрее работает и не создает лишнего мусора в памяти.
Статья новичка для хз кого,, полезности ноль.
Скажу новичкам пару советов: кэшируйте ссылки на компонентыних, если используется кодом чаще раза в секунду, у скриптов удаляйте пустые "магические" методы start, update. Если объектов со скриптами более 1к и, в них используется метод update, то делайте менеджеры для этих объектов и ими обновляйте состояние обьектов, а функцию update удаляйте. Так вы выйграете в несколько раз в скорости, пожертвовав отказоустойчивостью.

    private bool CheckObject(GameObject other)
    {
        if (other == null) return false;
        else return true;
    }

И тут я умер
return other != null для слабых

Глаз зацепился за это и решил разобраться.
Автор категорически не прав - использование типов short или byte для индексов в цикле только ухудшит ситуацию.

1. По сравнению со случаем использования int-индекса в данном случае в IL-коде инкремента будет еще функция преобразования <результата сложения индекса и единицы в стеке> в тип Int16(short). И в коде ассемблера, в который JIT-компилятор преобразует IL-код, эта лишняя работа никуда не исчезнет, а будет выглядеть как что-то вроде movsx eax, ax. То есть мы экономим 8 или 16 бит, но имеем гарантированно дополнительную работу в цикле. Это просто дичайше не целесообразно.

В целом байтодрочерство почти всегда не оправдано. Процессоры привыкли работать с 32-битными числами. Да и, думаю, не нужно объяснять, что, учитывая вышеописанные издержки, стараться сохранить несколько бит просто глупо. Тем более когда выравнивание данных может внезапно нивелировать драгоценные ваши старания по сохранению памяти..

alexprey, Хех, это абстракция ))

prog, Да, но я и не профессионал, чтобы делать обработку исключений и т.п.

а каждый такт искать в Update по отдельности каждую ось в непонятном контейнере

По другому сделать обработку нажатия клавиши с условием, что одна из переменных одна быть интерполирована в другое значение нельзя.
Функции, согласен, вышли почти одинаковы по названию, думаю исправить.

DasBro, а каждый такт искать в Update по отдельности каждую ось в непонятном контейнере это тоже только заготовка или так и должно быть? При том, что эта ось вроде как уже найдена найдена и лежит в переменной. отбой, понял что разные функции. не заметил сразу отличие в два символа. Но это всеравно не ок, имхо.

Ну и отсутствие проверок на фейлы это такое, дело вкуса.

prog, А проблема в том, что трекинг можно осуществить через костыль. Я думал об этом но, увы, если и использовать костыль, то дело ведь не в этом. Дело в полном отсутствии доступа к необходимым данным. Прямое использование - это ведь был грубый пример. В шаблоне же обработка идет с использованием "команды".

Проблема выглядит как-то искуственно. Что мешает трекать ввод для геймпада отдельно от мышки с клавиатурой, а не в одной оси, если от этого возникают проблемы? Да и прямое использование значений с устройств ввода в качестве трансформа выглядит как-то "опасно".
Впрочем, я юнити не пользуюсь, а в анриле свои проблемы с вводом.