James Liu

Redid the microbenchmarks including the ones in #5123. The results are odd. It does indeed show that even the wider queries benefit from this change. However, both of the `busy_systems`...

Further cross checking this against the results for before and after switching to values over references [4d27afc](https://github.com/bevyengine/bevy/pull/4800/commits/4d27afc335cfed2ac53a746144dc39b43981ecd6), the change here does seem to line up, and it's the only other...

Completed both benchmarks and a timing test against `many_cubes` and it does seem like it's coming from that change. The stage timings seem to suggest that `Query::get` is indeed faster...

One more thing I noticed is that this PR, regardless of which version (reference or value), substantially closes the gap between Query::iter and Query::for_each on the fragmented iteration cases. This...

Seeing how eagerly fetching entities/rows speeds up iteration, I noticed the same pattern when using `set_archetype` to fetch the table: we're passing in a `&Tables` reference that each `Fetch` is...

Another sanity check microbenchmark to ensure nothing since the rebase has affected the perf changes seen earlier: ``` group fetch-cleanup main ----- ------------- ---- add_remove/sparse_set 1.08 1268.9±87.23µs ? ?/sec 1.00...

> `QueryIterationCursor` needs to be updated Done.

Actual benchmark results here, and the differences here make plenty of sense. Tl;dr: it's really only beneficial to `par_for_each` and it's variants in the general case, otherwise the total number...

There were a few errors with how the prior benchmarks were run. There were 10, 100, 1000, 2000, 5000, and 10000 archetypes made, but not all of them matched the...

> I dont think its right to conclude this has no effect on normal `for_each`. The benchmark uses `Query` which is going to be doing barely any work on empty...