Skip to content

Accelerate wave-style spawning with the use of entity tombstoning #18697

Open
@alice-i-cecile

Description

@alice-i-cecile

What problem does this solve or what need does it fill?

Can we optimize the ECS to disable entities and keep them around in an archetype table, so instead of doing that work from scratch when you spawn an entity of some archetype, you just reuse the allocated one and mutate in place?
e.g. ui entities are often the same set of archetypes, and you might save a lot of time reusing them instead of full despawn/spawn.
(with an incremented entity version of course)

The core idea is pretty simple: if we're regularly spawning and despawning entities with the same archetypes, we're wasting time allocating (and in theory cleaning up) memory.

This comes up in immediate mode UI, but also in things like bullet hell and tower defense games, where large numbers of transient entities are spawned and despawned repeatedly.

What solution would you like?

Use entity disabling with a custom disabling component to tombstone these entities when they would otherwise be despawned.

Then, when you would spawn in a matching entity, simply reactivate the old entity and mutate its data.

We need to be careful to invalidate all of the relations (and other assorted references) to this entity. We could do this by assigning a new entity ID, as Aevyrie suggested, but that will leave us with dangling stale references. Instead, we probably want to run all of the hooks and observers as normal as if it were actually despawned.

What alternative(s) have you considered?

Do nothing! This might not be faster, given that we're doing two archetype moves with each cycle. Using sparse disabling components might help there, but you need to be really careful to ensure that you're not getting passive slowdowns during iteration of the living entities.

Optionally, you could check if the data needs to be mutated (via all sorts of interesting mechanisms) before overwriting it. It's not clear if and when that would be faster though: this would really need to be tunable.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ECSEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleD-ComplexQuite challenging from either a design or technical perspective. Ask for help!S-Needs-BenchmarkingThis set of changes needs performance benchmarking to double-check that they helpX-ControversialThere is active debate or serious implications around merging this PR

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions