Ну смотри, грубо говоря частица, на самом деле хранимая в том массиве - это не частица, а ссылка на неё (соответсвенно, Null если ссылки нет). Я могу конечно сильно ошибаться, но думаю, это так. Далее, ссылка - это 32 бита информации. Представим, что у тебя в стандартном таком массиве 1000 частиц (не зависимо от того, сколько их на самом деле). Тогда это 4кБ инфы. А теперь подумай, насколько много у тебя должно быть систем частиц единовременно, на какую оперативную память ты рассчитываешь и стоит ли париться.
Если я не прав на счёт ссылок, и в массиве действительно хранится элемент типа частицы, то навскидку кол-во инфы в таком типе:
x,y,z + то же самое для углов и масштабов = 9 float (а флоаты в б3д = 32 бита)
ещё 4 флоата - для цвета в формате RGBA (если по-хорошему (нужна избыточная инфа для HDR, но я не могу себе представить такую необходимость в б3д), по-плохому-то там и одного флоата достаточно
)
Ещё флоат - время жизни частицы
Ещё 3 флоата - направление перемещения от предыдущего шага (зная его, удобнее делать всякие спиральные траектории для, допустим, искр от костра) - ну это уже опция.
Итого в средне-гнущихся партиклах мы получаем... 14 флоат-переменных, что равно 14*4 = 56 байт на партикл. Опять же, 1000 партиклов ~ 56 кБ инфы в памяти.
Если у тебя конечно по 10000 партиклов в системе, да ещё самих систем частиц "хорошо за 100" - то это уже серьёзно, 56 МБ памяти на частицы. Но если это не так - я бы не заморачивался.