0.13: Fix author attribution in Entity Opt/Query for_each/TableRow sections (#986)

Author: Bluefinger

content/news/2024-02-17-bevy-0.13/index.md

@@ -1152,7 +1152,7 @@ Here's a short example of how declaring a new layout looks:
 
 ```rust
 let layout = render_device.create_bind_group_layout(
-    "post_process_bind_group_layout"),
+    "post_process_bind_group_layout",
     &BindGroupLayoutEntries::sequential(
         ShaderStages::FRAGMENT,
         (
@@ -1398,7 +1398,7 @@ See the [Asset Processing Example](<https://github.com/bevyengine/bevy/blob/main
 
 ## Entity Optimizations
 
-<div class="release-feature-authors">authors: @Bluefinger, @notverymoe, @scottmcm, @bushrat011899, @james7132</div>
+<div class="release-feature-authors">authors: @Bluefinger, @notverymoe, @scottmcm, @james7132, @NathanSWard</div>
 
 `Entity` (Bevy's 64-bit unique identifier for enitities) received a number of changes this cycle, combining laying some more groundwork for relations alongside _related_, and nice to have, performance optimizations. The work here involved a lot of deep-diving into compiler codegen/assembly output, with running lots of benchmarks and testing in order to ensure all changes didn't cause breakages or major problems. Although the work here was dealing with mostly _safe_ code, there were lots of underlying assumptions being changed that could have impacted code elsewhere. This was the most "micro-optimization" oriented set of changes in Bevy 0.13.
 
@@ -1429,6 +1429,8 @@ If that interests you, open some new tabs in the background!
 
 ## Porting `Query::for_each` to `QueryIter::fold` override
 
+<div class="release-feature-authors">authors: @james7132</div>
+
 Currently to get the full performance out of iterating over queries, `Query::for_each` must be used in order to take advantage of auto-vectorization and internal iteration optimizations that the compiler can apply. However, this isn't idiomatic rust and is not an iterator method so you can't use it on an iterator chain. However, it is possible to get the same benefits for some iterator methods, for which [#6773](https://github.com/bevyengine/bevy/pull/6773/) by @james7132 sought to achieve. By providing an override to `QueryIter::fold`, it was possible to port the iteration strategies of `Query::for_each` so that `Query::iter` and co could achieve the same gains. Not _every_ iterator method currently benefits from this, as they require overriding `QueryIter::try_fold`, but that is currently still a nightly-only optimisation. This same approach is within the Rust standard library.
 
 This deduplicated code in a few areas, such as no longer requiring both `Query::for_each` and `Query::for_each_mut`, as one just needs to call `Query::iter` or `Query::iter_mut` instead. So code like:
@@ -1457,6 +1459,8 @@ As a plus, the same internal iteration optimizations in `Query::par_for_each` no
 
 ## Reducing `TableRow` `as` Casting
 
+<div class="release-feature-authors">authors: @bushrat011899</div>
+
 Not all improvements in our ECS internals were focused around performance. Some small changes were done to improve type safety and tidy-up some of the codebase to have less `as` casting being done on various call sites for `TableRow`. The problem with `as` casting is that in some cases, the cast will fail by truncating the value silently, which could then cause havoc by accessing the wrong row and so forth. [#10811](https://github.com/bevyengine/bevy/pull/10811) by @bushrat011899 was put forward to clean up the API around `TableRow`, providing convenience methods backed by `assert`s to ensure the casting operations could never fail, or if they did, they'd panic correctly.
 
 Naturally, _adding_ asserts in potentially hot codepaths were cause for some concern, necessitating considerable benchmarking efforts to confirm there were regressions and to what level. With careful placing of the new `assert`s, the detected regression for these cases was in the region of 0.1%, well within noise.