Влияет ли больше уровней косвенности на производительность в C

Question

Влияет ли больше уровней косвенности на производительность в C

Если у меня есть структура, содержащая массив структур.... и на

config.data.item[3].userFunction();

это лучше для доступа с

itemType * item = &config.data.item;

item[3].userFunction();
item[4].userFunction();

или это так же, как

config.data.item[3].userFunction();
config.data.item[4].userFunction();

Или существует ограничение на количество уровней, на которых теряется эффективность, и влияет ли оптимизация компилятора?

Заранее большое спасибо за любые идеи.

0

c performance indirection multiple-indirection

Источник

user3893960 22 авг '14 в 18:29

2 ответа

Другие вопросы по тегам c performance indirection multiple-indirection

user335858 22 авг '14 в 18:37 2014-08-22 18:37 · Answer 1 · 2014-08-22 18:37

Уровни косвенности оказывают влияние, как с точки зрения циклов ЦП, так и с точки зрения читаемости. Однако в вашем случае существует только один уровень косвенности (указатель на функцию). Точечный оператор производит смещение к местоположению config во время компиляции.

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

user3437661 22 авг '14 в 18:53 2014-08-22 18:53 · Answer 2 · 2014-08-22 18:53

Даже если у вас есть прямые уровни косвенности, такие как a->b, где может быть потенциальный кэш и снижение производительности, даже невинно выглядящий abc[x].d необходимо тщательно изучить, так как [x] может очень хорошо вас оттолкнуть. из кеша.

поэтому ответ на самом деле зависит от того, что находится в кеше, насколько велик кеш и какой размер структур.

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

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