Доступ к массиву оценивает через адресную арифметику с указателями по сравнению с индексированием в C

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

Nah. Это - та же операция так или иначе. Индексирование является синтаксическим сахаром для добавления (размер элемента * индекс) к начальному адресу массива.

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

Это могло бы быть, немного вне темы (извините), потому что это не отвечает на Ваш вопрос относительно скорости выполнения, но необходимо полагать, что преждевременная оптимизация является корнем всего зла (Knuth). По-моему, особенно когда все еще (ре), учащее язык, любой ценой запишите ему способ, которым является самым легким читать сначала. Затем если Ваши прогоны программы корректный , рассмотрите скорость оптимизации. Большую часть времени Вы кодируете, будет достаточно быстро так или иначе.

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

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <iostream>

using namespace std;

typedef int64_t int64;
static int64 nsTime() {
  struct timespec tp;
  clock_gettime(CLOCK_REALTIME, &tp);
  return tp.tv_sec*(int64)1000000000 + tp.tv_nsec;
}

typedef int T;
size_t const N = 1024*1024*128;
T data[N];

int main(int, char**) {
  cout << "starting\n";

  {
    int64 const a = nsTime();
    int sum = 0;
    for (size_t i=0; i<N; i++) {
      sum += data[i];
    }
    int64 const b = nsTime();
    cout << "Simple loop (indexed): " << (b-a)/1e9 << "\n";
  }

  {
    int64 const a = nsTime();
    int sum = 0;
    T *d = data;
    for (size_t i=0; i<N; i++) {
      sum += *d++;
    }
    int64 const b = nsTime();
    cout << "Simple loop (pointer): " << (b-a)/1e9 << "\n";
  }

  {
    int64 const a = nsTime();
    int sum = 0;
    for (size_t i=0; i<N; i++) {
      int a = sum+3;
      int b = 4-sum;
      int c = sum+5;
      sum += data[i] + a - b + c;
    }
    int64 const b = nsTime();
    cout << "Loop that uses more ALUs (indexed): " << (b-a)/1e9 << "\n";
  }

  {
    int64 const a = nsTime();
    int sum = 0;
    T *d = data;
    for (size_t i=0; i<N; i++) {
      int a = sum+3;
      int b = 4-sum;
      int c = sum+5;
      sum += *d++ + a - b + c;
    }
    int64 const b = nsTime();
    cout << "Loop that uses more ALUs (pointer): " << (b-a)/1e9 << "\n";
  }
}

В быстрой основанной на Core 2 системе (g ++ 4.1.2, x64), вот синхронизация:

    Simple loop (indexed): 0.400842
    Simple loop (pointer): 0.380633
    Loop that uses more ALUs (indexed): 0.768398
    Loop that uses more ALUs (pointer): 0.777886

Иногда индексация быстрее, иногда адресная арифметика с указателями. Это зависит от, как ЦП и компилятор в состоянии конвейерно обработать выполнение цикла.

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

Теперь, если Вы имеете дело явно с блоком данных Вы malloc () 'd и Вы хотите получить указатель в тех данных, сказать 20 байтов в заголовке звукового файла, тогда я думаю, что адресная арифметика более ясно выражает то, что Вы пытаетесь сделать.

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

РЕДАКТИРОВАНИЕ: Согласно некоторым из этих других ответов, индексирование является просто syntacitic элементом и не имеет никакого эффекта на производительность как, я фигурировал. В этом случае определенно пойдите с любым контекстом, который Вы пытаетесь выразить через данные доступа в блоке, на который указывает указатель.

Следует иметь в виду, что скорость выполнения трудно предсказать, смотря на машинный код с суперскалярными CPU и т.п. с

• неисправный exection
• , конвейерно обрабатывающий
• предсказание ветвлений
• гиперпоточность
• ...

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

char p1[ ] = "12345";
char* p2 = "12345";

char *ch = p1[ 3 ]; /* 4 */
ch = *(p2 + 3); /* 4 */

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

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

, Таким образом, общие рекомендации должны использовать то, что дает более ясный и более простой код. Используя массив [я] даю некоторую способность к инструментам попытаться найти index-out-of-bound условия, поэтому если Вы используете массивы, лучше просто рассматривать их как таковой.

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

Нет, использование адресной арифметики с указателями не быстрее и по всей вероятности медленнее, потому что оптимизирующий компилятор может использовать инструкции как ЛЕА (Исполнительный адрес Загрузки) на процессорах Intel или подобный на других процессорах для адресной арифметики с указателями, которая быстрее, чем добавляют или add/mul. Это имеет преимущество выполнения нескольких вещей сразу и не осуществления флагов, и также требуется один цикл для вычисления. BTW, ниже из руководства GCC. Так -Os не оптимизирует, прежде всего, для скорости.

я также полностью согласен с themarko. Сначала попытайтесь записать чистый, читаемый и повторно используемый код и затем думать об оптимизации и использовать некоторые профильные инструменты для нахождения узкого места. Большую часть времени проблемой производительности является связанный ввод-вывод или некоторый плохой алгоритм или некоторая ошибка, которую необходимо выследить. Knuth является человеком;-)

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

-Os Оптимизируют для размера. Os включает всю оптимизацию O2, которая обычно не увеличивает размер кода. Это также выполняет дальнейшую оптимизацию, разработанную для сокращения размера кода.

Маловероятно, что будет любое различие в скорости.

Используя оператор массива [], вероятно, предпочтен, как в C++ можно использовать тот же синтаксис с другими контейнерами (например, вектор).

Это не верно. Это точно с такой скоростью, как с нижними операторами. В Objective C можно использовать массивы как в C и в объектно-ориентированном стиле, где объектно-ориентированный стиль намного медленнее, потому что это делает некоторые операции в каждом вызове из-за динамического характера вызова.