[Merged by Bors] - Slight perf improvements and tidy for bevymark#3765
[Merged by Bors] - Slight perf improvements and tidy for bevymark#3765SUPERCILEX wants to merge 15 commits intobevyengine:mainfrom SUPERCILEX:tmp
Conversation
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
examples/tools/bevymark.rs
Outdated
| ); | ||
| counter.color = Color::rgb_linear(random(), random(), random()); | ||
|
|
||
| let mut random = thread_rng(); |
There was a problem hiding this comment.
Because this is example code, could you please comment to explain why this is faster.
There was a problem hiding this comment.
You mean here or as a comment in the code? thread_rng uses an Rc under the hood so theoretically we save some instructions by not cloning it a bunch of times.
There was a problem hiding this comment.
Something like
// cache the rng
Might be enough enough here.
examples/tools/bevymark.rs
Outdated
|
|
||
| fn movement_system(time: Res<Time>, mut bird_query: Query<(&mut Bird, &mut Transform)>) { | ||
| for (mut bird, mut transform) in bird_query.iter_mut() { | ||
| bird_query.for_each_mut(|(mut bird, mut transform)| { |
There was a problem hiding this comment.
I think that using the for_each pattern here is worth it, but we should explain to beginners that this is faster (and ideally link to an explanation why).
There was a problem hiding this comment.
Agreed, I'd actually love to know why this is faster. This PR added it and said it was faster but not why.
There was a problem hiding this comment.
Added a note, though I have no idea if it's correct. 😅
There was a problem hiding this comment.
I can't comment on the correctness of that note, but I feel like something like
// `.for_each_mut` is faster than `.iter`, but can't be chained like a normal iterator.
would be enough. (based on text here https://docs.rs/bevy/latest/bevy/ecs/system/struct.Query.html#method.for_each_mut)
There was a problem hiding this comment.
Happy with the changes to use for_each, thread_rng, .single and a marker component. I'm conflicted on the change to use write, but I don't want to make the call for that.
The whitespace changes seem bizarre; rustfmt is 'borked' if it thinks the new version is better.
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
IceSentry
left a comment
There was a problem hiding this comment.
Since you are modifying this example, I would also add a short description of what it is at the top of the file or at least above main(). I would also add the explanation for the .for_each use there.
|
There are likely to be some differing opinions about this. Examples should probably be optimized for clarity, but a "benchmark example" like I agree that comments in place where a less-obvious thing is being done for performance reasons would be a good idea. |
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
alice-i-cecile
left a comment
There was a problem hiding this comment.
Looking good. One very small nit + approval from another team member, then I'm happy to merge this.
|
could you mention the kind of perf improvements you get from those changes? |
I don't think it's even really measurable... |
Testing locally, these changes are maybe a frame or two faster for me at reasonable entity counts. Very hard to measure precisely for this example though. |
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
On my end, with |
|
Sidenote: bevymark vsync got re-enabled (accidentally?) with #3812. Will PR separately later if I remember. |
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
@rparrett Fixed |
|
I don't think some of the changes in this PR are really useful as they make the example harder to read if they don't bring the perf improvements from the pr title |
|
@mockersf Can you point to specifics? The only thing that got more complicated is |
|
@rparrett is there anything you're still hesitant about or is this good for approval? |
|
I do think the "string allocation optimizations" are on a scale we don't need to worry about here. I agree that the extra complexity isn't worth it. Other than that, I think this is good to go! |
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
Sounds good, done! |
|
also, I wasn't a fan of using (sorry I took so long replying, I was busy with the jam and missed your reply) |
|
I was under the impression that |
|
The gap has definitely closed now that |
|
@mockersf Since it's part of the public API, I think it's actually good to showcase different ways of doing things. Also, nitpicking on this level is getting a little excessive IMO: you can't say X is faster in the docs and then complain when people use X. 🤷♂️ |
I think its important for examples to encourage "best practices" and "recommend coding styles". I have intentionally pushed for normal query iterators in examples because they are about as fast, more "idiomatic rust", more flexible (because you don't need to refactor to do iterator chaining), and more ergonomic. |
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
Yeah now that |
|
bors r+ |
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>


No description provided.