PersistentCommandBuffer is designed for memory efficiency when constructing the individual ECS "worlds" which relate to each scene. On construction of each scene, a new PersistentCommandBuffer is created which has a default capacity for each type of component. This is expanded mostly on scene loading as each entity is created and then is efficiently re-used.
On destruction of each scene (which will be happening often) the PersistentCommandBuffer is thrown away, which means it must be re-allocated once again once that scene comes back into the radius.
I think we have some options here:
We could persist the command buffers outside of the lifetime of the worlds themselves, in a simple "most recent" style algorithm. I believe this would ensure that the right command buffers would be used for the right worlds, with in general the capacities to avoid allocations. This wont ensure that initial scene loads avoid stuttering due to allocations though.
It may also make sense to have a shared pool of PersistentCommandBuffer's that we just re-use, this pool would then eventually expand to fit the needs of the surrounding scenes. Although it would constantly exist in memory, I do not think we need to be so worried about the extra MB's.
Notes
You can easily reproduce the effect in the editor.
Load dynamic scene loader
Wait for the spawn of the two animated cubes
Zoom away from the scene until they dissapear
Zoom back in until they reappear.
Notice the spikes due to allocations and arrays expandning.
m3taphysics
commented
1 month ago
Description
PersistentCommandBufferis designed for memory efficiency when constructing the individual ECS "worlds" which relate to each scene. On construction of each scene, a newPersistentCommandBufferis created which has a default capacity for each type of component. This is expanded mostly on scene loading as each entity is created and then is efficiently re-used.On destruction of each scene (which will be happening often) the
PersistentCommandBufferis thrown away, which means it must be re-allocated once again once that scene comes back into the radius.I think we have some options here:
We could persist the command buffers outside of the lifetime of the worlds themselves, in a simple "most recent" style algorithm. I believe this would ensure that the right command buffers would be used for the right worlds, with in general the capacities to avoid allocations. This wont ensure that initial scene loads avoid stuttering due to allocations though.
It may also make sense to have a shared pool of PersistentCommandBuffer's that we just re-use, this pool would then eventually expand to fit the needs of the surrounding scenes. Although it would constantly exist in memory, I do not think we need to be so worried about the extra MB's.
Notes
You can easily reproduce the effect in the editor.
Notice the spikes due to allocations and arrays expandning.