Consider shrinking ECS IDs

[james7132]

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

Currently all of the ECS IDs (sans Entity) is backed with a usize, which might be bigger than it needs to be. It'll be difficult to find a use case that legitimately needs more than u32::MAX archetypes, tables, bundles or components, which means the upper 4 bytes on 64-bit machines effectively go unused.

For Components and Bundles, it may make sense to drop to u16, as most of these are determined at compile time, or are conservatively added via modding/scripting.

What solution would you like?

Shrink ArchetypeId, TableId, ArchetypeComponentId to u32.

Tentatively shrink ComponentId and BundleId to u16.

What alternative(s) have you considered?

Leaving them as is.

Additional context

As a good portion of the metadata storage for ECS is stored in SparseSets embedded in Archetypes and Tables, shrinking these IDs can shrink the size of these sets, keeping them hotter in caches, and thus reducing access overhead.

[bjorn3]

Tentatively shrink ComponentId and BundleId to u16.

I don't think using 16bit would make anything faster. At least wasm and arm/aarch64 have most instructions operate on the full register width which is 32 or 64 bits.

[james7132]

Tentatively shrink ComponentId and BundleId to u16.

I don't think using 16bit would make anything faster. At least wasm and arm/aarch64 have most instructions operate on the full register width which is 32 or 64 bits.

The register may not change, but the layout in memory will. We'd be able to fit more of the SparseArray in cache at once, and more per cache-line. It'd also be much more bounded in size as well. Given that we do one of these lookups per component every time we initialize a Fetch, something we do every Query::get call, we could shave off quite a bit of overhead.

Though as always, probably best to measure first to see if the gains are worth the limitations.

[bjorn3]

I think it is very likely large games will exceed either 65536 components or 65536 bundles or both.

[HackerFoo]

This wasn't Bevy, but I recently generalized the graph node type used in Noumenal so that I could try switching from usize to u16 - doing so had no effect on performance, but reduced memory use by about 40%. u32 saved about 20%.

I recommend doing the same, and maybe select the type using a feature. Memory usage is important on mobile devices.