Insert ResolvedScenes as dynamic bundles

[cart]

Objective

Currently BSN inserts each component one-by-one. This is incredibly expensive, as it forces an archetype move after every insert.

Solution

Scene templates now write their outputs to reusable bundle scratch space (which uses a bump allocator). The final bundle is written after all components (including inherited components) are written to the bundle.

• Introduce a BundleWriter, which enables defining a dynamic bundle using scratch space in a bump allocator. Currently this only supports writing individual components to the BundleWriter, because supporting arbitrary bundles is much harder (ex: dynamic bundle effects). This sadly means that we are temporarily constraining both bsn! { Node } and bsn! { @SomeTemplate } "template patches" to require a component output. Custom scene impls can still push arbitrary bundles, which are inserted before the final dynamic bundle write. In practice I believe this will cover the relevant use cases in the short term.
• We now skip duplicate insertions of components when spawning inherited scenes.
• We now write empty RelationshipTarget collections, pre-allocated to the correct size to the dynamic bundle, which both avoids another archetype move and ensures we only allocate the inner relationship target collection once.
• We now write the Relationship component to the dynamic bundle, avoiding an archetype move
• I added a new "loaded scene inheritance" test variant, just to make sure that case still works
• ErasedTemplate has been moved to bevy_scene, as it is now "opinionated", more specific to bevy_scene, and less safe to use in a general context

These are benchmarks that produce the same UI scene hierarchy through different means (the benchmarks have been updated to have a few "matrix wrapper" components to show the cost of archetype moves):

• immediate_function_scene: a test of going through the whole "scene building" process, then spawning. this is the cost of ad-hoc scenes that don't reuse work from inherited scenes
• immediate_loaded_scene: a test where we instantiate a bunch of inherited scene instances, where the inherited scene has already been computed / cached.
• raw_bundle_no_scene: just spawning the raw bundle directly

[urben1680]

One thing, did not review the other things because they are a bit of deep water for me yet.

[alice-i-cecile]

I've left a number of comments on the details here, and I think there are a number of modest improvements we could make.

The main questions center around overall architecture though: this is quite a bit of tricky, very niche unsafe code.

Can we copy from the entity cloning machinery (which you called out when talking to @Shatur about related work in BEI)?

The core problem feels very similar to that, and I think that with some changes to how we manage ownership of scratch data we should be able to get something that compiles without the need for this level of sketchiness.

[Shatur]

If you have safety concerns, maybe just move it to bevy_scene and make the writer private?

But the API seems reasonable to me.

[alice-i-cecile]

Good: the by_id change was my primary concern, and the changes to merge OwnedBundleScratch into BundleWriter make this a bit more robust.

The drop thing would be nice to fix, but eh, probably not worth the overhead. I'm content with this.

[chescock]

If I'm reading this correctly, the only difference between BundleWriter and BundleScratch is that BundleScratch stores the Bump externally so it can rely on lifetimes a bit more for safety. Is that right? Will we want to do follow-up work to replace the uses of BundleScratch in the cloning code with BundleWriter?

[cart]

Doing so would give some perf wins, which in the context of cloning makes sense. So my vote is yes.

[chescock]

Why is this a trait, as opposed to leaving the methods non-generic and just passing an empty HashSet or using Option<HashSet>?

[cart]

I was in "skip all unnecessary work" mode. This saves us a branch on each entity spawn (if false {} is trivially optimized out). Given that there are only two versions, I don't think its a steep price to pay.

[urben1680]

This should mention to call this method at most once.

[cart]

There is no harm in calling this multiple times.

[urben1680]

Ah right my bad 👍