Блог

Главная - Вопросы по программированию - Доступ к статически выделенному массиву ПРОТИВ доступа через указатель на статически выделенный массив

Доступ к статически выделенному массиву ПРОТИВ доступа через указатель на статически выделенный массив

#c #arrays #string-literals

#c #массивы #строковые литералы

Вопрос:

Мне нужно сохранить количество строк (они останутся постоянными и не будут изменены) в массиве и обращаться к ним много раз, мы хотим добиться как можно более быстрого поиска. Что из приведенного ниже обеспечит более быстрый доступ:

Подход 1: 

 const char* string_literal[] = {"Test1","Dummy","Dummy","Test2","Test3","Dummy"}; //       storing as string literals
... ... ... ...
... ... ... ...
const char* string_literal1000[]= {"Beta1","Beta2","Beta3"};

Подход 2: 

 const char test1ptr[] = "Test1",
const char test2ptr[] = "Test2",
const char test3ptr[] = "Test3",
const char dummyptr[] = "Dummy",


const char* string_ptr1 [] = {test1ptr,dummyptr,dummyptr,test2ptr,test3ptr,dummyptr}; // storing as pointers
... ... ...
const char* string_ptr1000[] = {"Beta1","Beta2","Beta3"};

Или; это Approach1 и Approach2 приведут к одинаковой производительности?

Примечание:

  1. У меня будет около 1000 записей (например, string_ptr1, sting_ptr2 и т.д. Или string_literal1, string_literl2 и т.д.), Содержащих в среднем 20 строк (например, «test1», test2″и т.д..
  2. «Фиктивный» будет отображаться только с несколькими записями.

Комментарии:

1. string_literal1000 не будет компилироваться

2. И string_ptr1000 тоже не подойдет, и, помимо всего этого, это действительно последнее место в мире, где вам следует искать снижения производительности.

3. Это самая нелепая микрооптимизация, которую я когда-либо видел. Перестаньте тратить свое время и просто программируйте.

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

5. Везде, где у вас есть const char* , вы, вероятно, действительно имеете в виду const char* const .

Ответ №1:

string_literal1000 не будет компилироваться.

Простой ответ: скажем, одинаковая производительность (поскольку шаблон распределения идентичен).

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

Теперь, после всего сказанного, я могу представить ситуации, когда вы могли бы немного оптимизировать с помощью следующего шаблона: ЕСЛИ вы знаете длину самой большой записи (они кажутся довольно маленькими), вы могли бы оптимизировать всю таблицу, упаковав ее в один char[] , содержащий отдельные строки, выровненные и дополненные хорошим количеством байт (скажем, 16 или 32 для строк, показанных в OP).

Без дополнительной информации о реальном сценарии кода было бы неправильно рекомендовать такой подход (IMO).