Performance regression in many_buttons since "render-set reorder"

[rparrett]

Bevy version

since #9236

Relevant system information

AdapterInfo { name: "Apple M1 Max", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
SystemInfo { os: "MacOS 13.5.1 ", kernel: "22.6.0", cpu: "Apple M1 Max", core_count: "10", memory: "64.0 GiB" }

What you did

Benchmarking in release mode for 500 frames and a tweaked FrameTimeDiagnosticsPlugin that keeps every sample for averaging.

Benchmarked before/after some PRs that seemed like they could affect this. Clearly missed some.

What went wrong

tag	fps	vs 0.11.3
0d23d71 0.11.3	54.98
e8b3892 pre-9236	55.68	🟢 +1.3%
4f1d9a6 render-set reorder	37.76	🔴 -31.3%
40c6b3b pre-9497	40.18	🔴 -26.9%
02b520b 9497 split computedvisibility	40.27	🔴 -26.8%
c8f61c3 pre-9712	41.80	🔴 -24.0%
73447b6 9712 many_buttons enhancements	43.54	🔴 -20.8%
e60249e pre-9685	43.48	🔴 -20.9%
5c884c5 9685 autobatching	42.47	🔴 -22.8%
35d3213 pre-9903	42.15	🔴 -23.3%
b6ead2b 9903 entityhashmap	37.15	🔴 -32.4%
2b5dac4 (unmerged) 9610 ui batching fix	44.47	🔴 -19.1%

[superdump]

I was going to try to make use of an instance rate vertex buffer for UI in the same way as for sprites but it was a bit too complicated to figure out. @ickshonpe has a bunch of performance PRs open for UI though as I recall.

[superdump]

Moving from the current vertex buffer approach to using an instance-rate vertex buffer gave a 40% improvement, which if it would carry over to UI, and I think it should, would get us back up to 50fps and there'd be no overall regression.

Then longer-term I intend to work on getting rid of as many lookups as possible such that the performance losses from the render set reorder architectural change 'requiring' to do random access lookups in the prepare set, and using EntityHashMap for those lookups, will go away. My goal is to get to iterating over items in Vecs.

[superdump]

So, basically, implement #9597 for UI.