Улучшает ли вызов константы по ссылке производительность при применении к примитивным типам?

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

Настройка производительности на основе догадок работает примерно в 0% случаев в C ++ (это внутреннее чувство, которое я испытываю к статистике, обычно это работает ...)

Верно, что const T& будет меньше, чем T, если sizeof(T) > sizeof(ptr), поэтому обычно 32-битное или 64-битное, в зависимости от системы.

Теперь спросите себя:

1) Сколько встроенных типов больше 64 бит?

2) Разве копирование 32-битного кода не стоит того, чтобы сделать код менее понятным? Если ваша функция становится значительно быстрее из-за того, что вы не копировали в нее 32-битное значение, возможно, это не так много?

3) Вы действительно настолько умны? (предупреждение о спойлере: нет.) См. этот отличный ответ по той причине, почему это почти всегда плохая идея: https://stackoverflow.com/a/4705871/1098041

В конечном итоге просто переходите по стоимости. Если после (тщательного) профилирования вы обнаруживаете, что какая-то функция является узким местом, а всех других оптимизаций, которые вы пробовали, было недостаточно (и вы должны попробовать большинство из них до этого), переходите к const-reference.

Тогда смотри, что это ничего не меняет. переворачиваться и плакать.

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

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

Так что даже для «небольших объектов» может быть быстрее просто передать значение.

(Я прочитал это в очень хорошей книге: Компьютерные системы: взгляд программистов)

Еще несколько интересных обсуждений по теме попаданий / промахов в кеш: Как написать код, который лучше всего использует кэш ЦП для повышения производительности?

В 64-битной архитектуре нет примитивного типа - по крайней мере, в C ++ 11 - который больше, чем указатель / ссылка. Вы должны проверить это, но интуитивно понятно, что для const T& должно быть столько же данных, сколько для int64_t, и меньше для любого примитива, где sizeof(T) < sizeof(int64_t). Поэтому, поскольку вы можете измерить любую разницу, передача примитивов по значению должна быть быстрее , если ваш компилятор делает очевидную вещь --- вот почему я подчеркиваю, что если вам нужна определенность здесь, вы должны написать тестовый пример.

Еще одно соображение заключается в том, что параметры примитивных функций могут попадать в регистры ЦП, что делает доступ к ним таким же быстрым, как и доступ к памяти. Вы можете обнаружить, что для ваших const T& параметров создается больше инструкций, чем для ваших T параметров, когда T является примитивом. Вы можете проверить это, проверив вывод ассемблера вашим компилятором.

const - это ключевое слово, которое оценивается во время компиляции. Это не влияет на производительность во время выполнения. Подробнее об этом можно прочитать здесь: https://isocpp.org/wiki/faq/const-correctness

Меня учили:

• Передача по значению, если переменная аргумента является одним из основных встроенных типов, например bool, int или float. Объекты этих типов настолько малы, что передача по ссылке не приводит к повышению эффективности. Также, если вы хотите сделать копию переменной.

• Передайте постоянную ссылку, если вы хотите эффективно передать значение, которое не нужно изменять.

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