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

записях есть разница?

вообще пофиг. Есть крайне редкие и очень извращенные кейсы когда конст "поможет" компилятору, но это уже высшие материи богов плюсого олимпа

По const куча тонкостей. Советую почитать про них.

Про вообще const. Получить крах с ним можно в любой ситуации

Ну модификатор const по сути для комплиятора означает, что модифицирующие операции над ним запрещены. Но у нас может быть так const type x = 3; // Можно type y = x; type& z = x; // Нельзя const type& t = y; /* Тоже можно. Просто теперь компилятор думает, что как y менять можно, а как t нельзя */

Ну тип для меня это в свое время было открытием. И как-то в голове укладывалось сложно. Тип у тебя есть объект, ты инициализируешь ссылку константную. Через неё менять нельзя, а напрямую можно

разницы нет, это любой большой компилятор уже лет десять успешно к одному и тому же сведет на самом агрессивном уровне оптимизации (-O3, /Ox и т.д.), в итоге по регистрам одни и те же чиселки будут прыгать

тут вообще нет разницы, тут дело в корректности последующих правок больше

это ты объяснил что к чему может байндиться; но тут вообще подвоха нет, разве что const type& t продлевает лайфтайм y, и если бы вместо y был вызов функции, то смысла было бы больше) бОльшие проблемы возникают с указателями, со strict aliasing, которые с помощью restrict из Сей решаются

как определение влияет на скорость сборки то? ну те на значимые числа, а не наносекунды "формально оно что-то делает"

Если проект большой эти наносекунды могут не слабо повлиять. Я на больших проектах не участвовал. Есть же рекомендации использовать '/n', а не 'std::endl'

Вообще никак. Совсем никак.

Использовать- при явном объявлении, когда из 1 строки понятно, что за тип, не использовать- в обратном случае