Стоимость доступа к динамически созданным объектам с динамически выделенными элементами

Если у вас есть веская причина заботиться о производительности...

Может ли динамическое выделение v означать, что экземпляр A и его элемент v не находятся в памяти вместе?

Если они оба выделены как «новые», то вполне вероятно, что они будут рядом друг с другом. Однако текущее состояние памяти может существенно повлиять на этот результат, оно существенно зависит от того, что вы делали с памятью. Если вы просто разместите тысячу таких вещей одну за другой, то более поздние почти наверняка будут «почти смежными».

Если экземпляр A находится в стеке, маловероятно, что его 'v' будет поблизости.

Если такая фрагментация является проблемой производительности, существуют ли какие-либо методы, позволяющие A и v размещаться в непрерывной области памяти?

Выделите место для обоих, а затем поместите их в это пространство. Это грязно, но обычно должно работать:

char* p = reinterpret_cast<char*>(malloc(sizeof(A) + sizeof(A::v)));
char* v = p + sizeof(A);
A* a = new (p) A(v);

// time passes

a->~A();
free(a);

Или существуют какие-либо методы для облегчения доступа к памяти, такие как схема предварительной выборки?

Предварительная выборка зависит от компилятора и платформы, но многие компиляторы имеют для этого встроенные функции. Имейте в виду - это не очень поможет, если вы попытаетесь получить доступ к этим данным сразу, поскольку предварительная выборка может иметь какое-либо значение, вам часто нужно делать это за сотни циклов, прежде чем вам нужны данные. Тем не менее, это может дать огромный прирост скорости. Встроенная функция будет выглядеть примерно так: __pf(my_a->v);

Если бы размер v или допустимый максимальный размер мог быть известен во время компиляции, приведет ли замена v массивом фиксированного размера, например int v[max_length], к лучшей производительности?

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

Специфика зависит от того, каковы ваши цели дизайна и производительности. Интересное обсуждение этого вопроса с «реальной» конкретной проблемой на конкретном оборудовании с конкретным компилятором см. в Подводные камни объектно-ориентированного программирования (это ссылка в Документах Google для PDF-файла, сам PDF-файл можно найти здесь).

Может ли динамическое выделение v означать, что экземпляр A и его элемент v не находятся в памяти вместе?

Да, это будет скорее всего.

Какие инструменты и методы можно использовать для проверки того, является ли эта фрагментация узким местом в производительности?

кешгринд, акула.

Если такая фрагментация является проблемой производительности, существуют ли какие-либо методы, позволяющие A и v размещаться в непрерывной области памяти?

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

Или существуют какие-либо методы для облегчения доступа к памяти, такие как схема предварительной выборки? например, получить объект типа A, работающий с другими переменными-членами при предварительной выборке v.

Да, вы могли бы сделать это. Лучше всего было бы разместить области памяти, используемые вместе, рядом друг с другом.

Если бы размер v или допустимый максимальный размер мог быть известен во время компиляции, приведет ли замена v массивом фиксированного размера, например int v[max_length], к лучшей производительности?

Может быть, а может и нет. По крайней мере, это сделало бы v локальной для членов структуры.

1. Напишите код.
2. Профиль
3. Оптимизировать.

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

Не могли бы вы просто иметь одну копию структуры и один (большой) буфер v, прочитать в него свои данные (в двоичном формате, для скорости), сделать очень небольшой расчет и перейти к следующему.

Программа должна тратить почти 100% времени на ввод-вывод. Если вы приостановите его несколько раз во время его работы, вы должны видеть его почти каждый раз в процессе вызова системной процедуры, такой как FileRead. Некоторые профилировщики могут дать вам эту информацию, за исключением того, что у них, как правило, аллергия на время ввода-вывода.