Проще говоря: этот совет по оптимизации вводит в заблуждение.Не обязательно неправильно, но не полностью.
Похоже, ваш источник был CodeProject .Он утверждает, что в основном говорит об оптимизации для ARM.
Во-первых, процесс обработки символов и коротких строк сильно зависит от процессора.В зависимости от архитектуры преобразования могут иметь нулевую или минимальную стоимость, в зависимости от того, когда и как они происходят - во время загрузки, типа операции, какие инструкции могут выполняться параллельно и, по сути, могут быть бесплатными, в зависимости от остальной частикод - например, в архитектуре TI DSP c64, которая может выполнять 8 операций за такт.Как правило, наиболее эффективным использованием будет «родной» целочисленный размер, но это также зависит от того, откуда поступают данные - может быть более эффективно загружать, изменять и сохранять данные char / short, чем загружать и преобразовывать в int,изменить и сохранить обратно как char / short.Или нет - это зависит от архитектуры и выполняемых операций.Компилятор часто лучше смотрит, стоит ли делать это за вас или нет.
Во-вторых, во многих многих архитектурах char и short такие же быстрые, как int, особенно если в вычислениях избегаются неявные преобразования в int.Примечание: это легко испортить в C, например, "x = y + 1" - это приводит к преобразованию до int (при условии, что x & y - char или short), но хорошо то, что почти все компиляторы достаточно умны, чтобыоптимизировать конверсию для вас.Во многих других случаях наличия локального be char / short компилятор оптимизирует любые преобразования в зависимости от того, как он будет использован позже.Это подтверждается тем фактом, что в типичных процессорах переполнение / обертывание char / short - это тот же результат, что и вычисление его как int и преобразование в хранилище (или просто обращение к этому регистру как char / short в более позднемоперация - получение преобразования для «free»).
В их примере:
int wordinc (int a)
{
return a + 1;
}
short shortinc (short a)
{
return a + 1;
}
char charinc (char a)
{
return a + 1;
}
Во многих архитектурах / компиляторах они будут работать на практике одинаково быстро.
В-третьих, в некоторых архитектурах char / short на 1017 * быстрее, чем int.В качестве примера можно привести встроенные архитектуры с естественным размером 8 или 16 бит (по общему признанию, это не тот вид развития, о котором вы думаете в настоящее время).
Четвертый, хотя и не слишком большой вопрос, как правило, в современной тяжелой, большой-cache процессорные среды, поддерживая размер локального стека (если компилятор не выводит его в регистр), может помочь повысить эффективность доступа к кешу, особенно кешам уровня 1.
С другой стороны,Если компилятор не достаточно умен, чтобы скрыть его от вас, локальные символы / шорты, передаваемые в качестве аргументов другим функциям (особенно не файловым «статическим» функциям) могут повлечь преобразование с повышением в int .Опять же, как указано выше, компилятор вполне может быть достаточно умным, чтобы скрыть преобразование.
I do согласен с этим утверждением в начале цитируемого вами сайта:
Несмотря на то, что имеется ряд руководств по оптимизации кода на C, ничто не заменит глубокое знание компилятора и машины, для которой вы программируете.