Reduce steady-state allocations in ui_stack_system

[UkoeHB]

Objective

• Reduce allocations on the UI hot path.

Solution

• Cache buffers used by the ui_stack_system.

Follow-Up

• sort_by_key is potentially-allocating. It might be worthwhile to include the child index as part of the sort-key and use unstable sort.

[UkoeHB]

For some reason my rust analyzer is erroring on the Label in bevy_ui/stack.rs, with message "const STORAGE_TYPE is not a member of trait Component".

[alice-i-cecile]

For some reason my rust analyzer is erroring on the Label in bevy_ui/stack.rs, with message "const STORAGE_TYPE is not a member of trait Component".

Do a cargo clean: this was recently changed.

[james7132]

Generally looks good, though I'd like to see some actual benchmarks. many_buttons and the other UI stress tests are probably the best scenarios to check.

I'm not too happy with the idea of a Vec per non-leaf node being allocated here, even in the cached steady state. Ideally we would just use one giant Vec and retain ranges, but this can be attempted in a follow up PR.

[UkoeHB]

Ideally we would just use one giant Vec and retain ranges, but this can be attempted in a follow up PR.

Yeah that would be ideal, issues to consider:

• The global Vec size isn't known ahead of time, so you need two Vecs.
• How to sort parents vs children properly.

many_buttons and the other UI stress tests are probably the best scenarios to check.

I will try these.

[UkoeHB]

Perf test for many_buttons. I'm at a loss to explain this, main is apparently significantly faster than this branch for the ui_stack_system (yellow main, red branch).

[UkoeHB]

That's more like it lol, I failed to cache one of the vecs.

[alice-i-cecile]

This needs docs if it's public. I would probably add docs for internal users and doc(hidden) this.

[UkoeHB]

It's public because the system is public even though it isn't actually exported. The visibility controls in this module don't make any sense.

EDIT: Added a commit to clean up visibility in this module.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[alice-i-cecile]

@james7132 I don't think this was actually breaking: the types weren't publicly exported despite the pub visibility.