Will there be any issues with using Vec as a storage in Bevy ECS?

[maxxie186]

Hello, maintainers! Could you spare me a moment to address my concerns？Thank you！

1. According to the Vec's expansion rules, it need to copy all the data to a new piece of memory. If there is a Table with too many Entity , will there be a performance hit when this Table's storage needs to be expanded? When a Table needs to be expanded, each Column's Vec of it needs to to be expanded, there is huge amount of data needs to be copied.
2. Vec has no capacity reduction mechanism. If the entities in a Table increase significantly, but only few of entities remains affterwards, that will result in a waste of memory.
3. Can it make good use of the principle of spatial locality? The data of each Component is stored in a separate Vec, which means their location in memory are not related. In Bevy's repo, I saw there are many System query a lot of Component at once and read&write them in arbitrary order. Does loading data from a different Component imply a refresh of the cache line？

If these concerns are indeed valid, I think the Archetype Chunks in Unity may work.

[drawliin]

concerns are justified however i feel like these can be broken down into different categories..

1. growth: Table::reserve grows the entity Vec and then reallocates the component columns to match its new capacity. the columns themselves use BlobArray, not literally Vec<T>. BlobArray::realloc calls the allocator's realloc, which may grow an allocation in place or move it.

   so yes, a large table crossing its capacity can cause an allocation spike, potentially moving substantial data. but this doesn't happen on every entity insertion.

   source: table/mod.rs:400-421, blob_array.rs:286-310

2. shrinking: rust's Vec does have shrink_to_fit(), but bevy doesn't automatically shrink table allocations when entities are removed. swap_remove_unchecked removes the entity without shrinking, and Table::clear clears the data while retaining allocations.

   so memory can stay allocated after a temporary population spike. reusing that capacity also avoids repeated allocations if the population grows again.

   source: table/mod.rs:227-255, table/mod.rs:551-558

3. cache locality: bevy uses a structure-of-arrays layout. each component column is contiguous, which is useful when iterating that component across many entities. a query accessing several components does follow several memory streams, but accessing another column doesn't automatically flush the previous cache line. the cpu can keep multiple cache lines resident.

   chunked storage could improve locality for some multi-component queries, but it introduces different tradeoffs. the actual benefit depends on component sizes, query access patterns, and workload.

   source: table/mod.rs:187-196

to confirm the allocation and removal paths in a bevy checkout:

rg -n 'fn reserve\(|fn clear\(|swap_remove_unchecked|alloc::alloc::realloc' crates/bevy_ecs/src/storage/table/mod.rs crates/bevy_ecs/src/storage/blob_array.rs

i verified these paths against the source at commit 85503941, but haven't benchmarked reallocation costs or compared them against unity's chunk layout.

[maxxie186]

Thank you for your answer. It's helpful to me