Queries should have less overhead

[Ukendio]

Roughly 80% of our queries bottleneck are preventing iterator invalidation and unpacking columns. The latter of which we have a decent solution at #27

However iterator invalidation is pretty tricky involving a great amount of change to the storage. We could explore improving what we have but this is honestly quite a large endeavor that I am not 100% sure I am confident in. Alternatively, explore pushing out command buffers and force people to use that to prevent iterator invalidation. However, it would be really unexpected as we already handle it apart of our current API and would effectively break user expectations. Our only chance to changing this is at v1 or sequential major versions.

If we explore command buffers, we could also integrate this specific feature baked into world like flecs. Like their world.defer_begin() and world.defer_end() methods which toggles the feature that stages changes to the next frame. We can then make loop invoke these features implicitly.

And if something happens that could invalidate the current thing you're iterating, you'll get an assert.

This would however break some things, e.g. it breaks the expectation where -world:insert() updates immediately and :get retrieving the immediate representation of its state - when ran in Loop.

[Ukendio]

Removing the pristine storage + making hotpaths largely boosts performance

[LastTalon]

I think if we go with a strategy like this it's important to get pipelines/schedules in alongside or before it. This is part of what those are meant to help abstract, since many systems will not have an awareness of distant systems and what they do, e.g. replication will not have a care what the rest of your ECS is doing, but will want the buffered changes applied before running.