C массив указателей и массив необработанных значений: производительность и память

Question

У меня есть 3D-игра, в которой объекты хранятся в 3D-массиве.Каждый объект представляет собой struct относительно большого размера (несколько мегабайт, если быть точным, 4 194 304 байта).

Если я сохраню их как массив необработанных значений: gameObject objects[64][64][8], все они будут сохранены водно место, но каждый объект выделяется независимо от того, используется он или нет.
Однако, если я выделю массив как массив указателей: gameObject *objects[64][64][8], неиспользуемые объекты (которые могут составлять более половины всего массива) не будет выделяться до тех пор, пока они не понадобятся, что уменьшит влияние на память, но может быть медленнее, поскольку объекты находятся во всей памяти

Принимая во внимание компромисс между производительностью и использованием памяти, какой подход лучше?Мои опасения действительны?

Answer 1

[второй подход] может быть медленнее, потому что объекты находятся во всей памяти

Поскольку каждый объект имеет размер 4 МБ, локальность ссылок на различные объекты почти наверняка не является проблемой. Перейти со вторым подходом.

Если числа, которые вы нам сообщаете, верны, для полностью заполненного массива объектов размером 128x128x128 4 МБ потребуется около 8 ТБ ОЗУ, что делает первый подход несколько неосуществимым на обычном оборудовании. ; -)

Answer 2

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

Answer 3

После того, как ваш комментарий сказал, что вам нужно только 500 МБ ОЗУ (ваш вопрос теперь указывает 128 ГБ ОЗУ ...), можно сравнить два варианта, так как оба являются жизнеспособными.

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

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