Open alice-i-cecile opened 3 years ago
We should also include despawn_batch
as part of this PR (or in an immediate follow-up PR) for performance reasons.
I don't think despawn_batch would meaningfully benefit from batching. Removing arbitrary entities is random-access (even if you somehow managed to sort by archetype, the internal swap remove would still be random). And the recent Commands rework ensures that we reuse allocations. In fact, despawn(a), despawn(b), ...
would be faster than despawn_batch(![a, b, ...])
because we could reuse the command allocations across frames, whereas the Vec would need to be allocated each frame.
What problem does this solve or what need does it fill?
Inserting and removing components one at a time is slow.
What solution would you like?
Add
Commands::insert_batch
andremove_batch
to modify components en-masse in a more efficient way.What alternative(s) have you considered?
Work towards #1613 for component modification and exclusively use that in performance-critical code.
We could use
insert_or_spawn_batch
for the insertion case, but that does not fail in the desired ways at all.Additional context
Follows up on the work from #2673, which added
insert_or_spawn_batch
. Ideally we can use the same strategy for this work, and perform similar benchmarks.