Рациональное использование памяти, сборщик мусора

Задача определить такую структуру данных:
Entity - Мешок для компонентов. Есть массив фиксированных компонентов. Это означает, что эти компоненты большую часть времени живут в сущности, но все-таки могут быть заменены или удалены. То есть нам выделять память для больше N элементов никогда не придется. Есть пузырьковые компоненты. Для них используется динамически расширяемый List<T>. У сущности есть ее идентификатор int.
Я знаю, что настоящая работа, которую совершает сборщик - составление графа живых объектов.
Если бы я объявил все вышесказанное в Entity - классе, то тогда я так понимаю дерево было бы куда более сложным, нежели если объявлять все компоненты в одном массиве (+ листе для пузырьковых компонентов), а потом чудо-производительными методами определять принадлежность к определенной Entity. В Entity в свою очередь будут свойства-функции, которые по факту будут обращаться к EntityManagerу с просьбой найти соответствующие компоненты. Но по идее в любом случае сборщик должен определить все варианты, и соответственно построить ветви графа и для этих функций. Короче говоря никакой оптимизации от одного большого массива я не вижу. Ето есть так?

0

Сообщение от kolorotur А как будете тогда реализовывать обращение к элементу по индексу?

В моей задаче первичный индекс - статичный идентификатор (id = index). То есть List<T> не подходит априори т.к. меняет индексы. Я что-то об этом не подумал.)

0