Если у вас есть веская причина заботиться о производительности ...
Может быть, динамически выделенный 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], приведет к улучшению
производительность
Может быть. Если буфер фиксированного размера обычно близок к нужному размеру, это может привести к значительному увеличению скорости. Таким образом, всегда будет быстрее получить доступ к одному экземпляру, но если буфер является чрезмерно гигантским и в значительной степени неиспользуемым, вы потеряете возможность для добавления большего количества объектов в кэш. То есть Лучше иметь в кеше меньше объектов, чем неиспользуемых данных, заполняющих кеш.
Особенности зависят от ваших целей дизайна и производительности. Интересная дискуссия по этому вопросу с конкретной проблемой «реального мира» на конкретном оборудовании с определенным компилятором, см. Подводные камни объектно-ориентированного программирования (это ссылка на Документы Google для PDF, Сам PDF можно найти здесь ).