Не смог найти в заголовках EASTL реализации с такими же возможностями.
Структура, от которой наследуется релизованный там vector:
template <typename T, typename Allocator>
struct VectorBase
{
T* mpBegin;
T* mpEnd;
T* mpCapacity;
allocator_type mAllocator; // To do: Use base class optimization to make this go away.
}
Особенно понравилось To do.
Но ведь всё равно в структуре модели нужно иметь поле данных, в который запишется указатель на этот созданный массив. Cобственно, предложенная в статье реализация по этому принципу и работает.
Давайте рассмотрим на примере. Есть модель (дерево, лавочка, машинка), требуется уметь повреждать эту модель — рисовать на ней какие-то следы повреждений. Хранить информацию о повреждениях удобно в массиве. В начале игры все модели как новенькие, без всяких повреждений и все эти массивы пусты.
Альтернатива — хранить повреждения в ассоциативном контейнере, и при отрисовке модели искать соответствующие ей повреждения, но этот поиск потребует значительно больше вычислительных затрат, чем просто пройтись по массиву.
То есть альтернатива есть, но она тоже имеет цену, и эта цена выше 4-х байт в структуре модели.
Нужно сказать, что желание иметь более компактный массив возникла ещё в конце 90-х, когда памяти было совсем не так много, как сейчас, и целью была именно оптимизация по памяти. Время шло, объём памяти увеличивался, но тем не менее оптимизация по памяти (теперь уже по кэш-памяти) всё ещё актуальна. Описанную реализацию я использую довольно давно (с 2006 года), и для того чтобы привести реальные цифры в статье для сравнения пересобрал проект со стандартным контейнером.
Так что это не было какой-то специальной оптимизацией последнего времени.
Тем не менее сейчас проект находится в таком состоянии, что профайлер не показывает пиков больше 5% на функцию, а самая «тяжёлая» подсистема (набор функций) занимает порядка 20%. И одним из узких мест оказывается память. Поэтому приходится думать и о втискивании структур в кэш-строки, и об их выравнивании.
В общем оптимизация в 1% это совсем неплохо, десяток таких оптимизаций и вот вам дополнительные 5 FPS.
Структура, от которой наследуется релизованный там vector:
template <typename T, typename Allocator>
struct VectorBase
{
T* mpBegin;
T* mpEnd;
T* mpCapacity;
allocator_type mAllocator; // To do: Use base class optimization to make this go away.
}
Особенно понравилось To do.
Альтернатива — хранить повреждения в ассоциативном контейнере, и при отрисовке модели искать соответствующие ей повреждения, но этот поиск потребует значительно больше вычислительных затрат, чем просто пройтись по массиву.
То есть альтернатива есть, но она тоже имеет цену, и эта цена выше 4-х байт в структуре модели.
Так что это не было какой-то специальной оптимизацией последнего времени.
Тем не менее сейчас проект находится в таком состоянии, что профайлер не показывает пиков больше 5% на функцию, а самая «тяжёлая» подсистема (набор функций) занимает порядка 20%. И одним из узких мест оказывается память. Поэтому приходится думать и о втискивании структур в кэш-строки, и об их выравнивании.
В общем оптимизация в 1% это совсем неплохо, десяток таких оптимизаций и вот вам дополнительные 5 FPS.