-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - Slight perf improvements and tidy for bevymark #3765
Conversation
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
examples/tools/bevymark.rs
Outdated
@@ -72,67 +75,74 @@ fn scheduled_spawner( | |||
scheduled.per_wave, | |||
bird_texture.0.clone_weak(), | |||
); | |||
counter.color = Color::rgb_linear(random(), random(), random()); | |||
|
|||
let mut random = thread_rng(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because this is example code, could you please comment to explain why this is faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like
// cache the rng
Might be enough enough here.
examples/tools/bevymark.rs
Outdated
@@ -209,19 +222,19 @@ fn spawn_birds( | |||
} | |||
|
|||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a note, though I have no idea if it's correct. 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.