-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Use spawn_batch
in many_lights
example
#11979
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BD103
added
A-Rendering
Drawing game state to the screen
C-Examples
An addition or correction to our examples
labels
Feb 19, 2024
james7132
approved these changes
Feb 19, 2024
MiniaczQ
approved these changes
Feb 25, 2024
IceSentry
approved these changes
Feb 25, 2024
IceSentry
added
the
S-Ready-For-Final-Review
This PR has been approved by the community. It's ready for a maintainer to consider merging it
label
Feb 25, 2024
msvbg
pushed a commit
to msvbg/bevy
that referenced
this pull request
Feb 26, 2024
# Objective - The `many_lights` example uses a for-loop around `commands.spawn`. - It is generally recommended to use `spawn_batch` instead to lazily spawn entities, because it doesn't massively grow the command queue. ## Solution - Use `spawn_batch` in `many_lights` example. --- ## Discussion - `thread_rng` is called for each light spawned. This is a simple thread-local `Rc` clone, so it should compile down to a copy and an increment + decrement instruction. - I created `golden_ration` outside of the closure and `move`d it in. This should just be a copy and hopefully will get const-evaluated away. Would it be better to just move it into the closure itself? ## Performance Using `spawn_batch` seems to decrease time-to-first-`Update` by 0.1s: 1.3s to 1.2s. <details> <summary>Raw data and how it was collected.</summary> Before: - 2024-02-19T15:18:57.650987Z to 2024-02-19T15:18:58.912244Z : 1.3 - 2024-02-19T15:19:25.277135Z to 2024-02-19T15:19:26.542092Z : 1.3 - 2024-02-19T15:19:46.841460Z to 2024-02-19T15:19:48.137560Z : 1.3 After: - 2024-02-19T15:17:05.749521Z to 2024-02-19T15:17:06.993221Z : 1.2 - 2024-02-19T15:17:38.153049Z to 2024-02-19T15:17:39.393760Z : 1.2 - 2024-02-19T15:18:10.691562Z to 2024-02-19T15:18:11.891430Z : 1.2 To time performance, I tracked the time from the first `Startup` logged message to the first `Update` logged message. ```shell $ cargo run --release --example many_lights Compiling bevy v0.13.0 (/Users/bdeep/dev/bevy/bevy) Finished release [optimized] target(s) in 1.54s Running `target/release/examples/many_lights` # THIS TIME 2024-02-19T15:30:13.429609Z INFO bevy_render::renderer: AdapterInfo { name: "Apple M1", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal } 2024-02-19T15:30:13.566856Z INFO bevy_winit::system: Creating new window "many_lights" (0v1) 2024-02-19T15:30:13.592371Z WARN many_lights: This is a stress test used to push Bevy to its limit and debug performance issues. It is not representative of an actual game. It must be run in release mode using --release or it will be very slow. 2024-02-19T15:30:13.592572Z INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "MacOS 14.2.1 ", kernel: "23.2.0", cpu: "Apple M1", core_count: "8", memory: "16.0 GiB" } # TO THIS TIME 2024-02-19T15:30:15.429900Z INFO many_lights: Lights: 100000 2024-02-19T15:30:15.430139Z INFO bevy diagnostic: fps : 0.982693 (avg 43.026557) 2024-02-19T15:30:15.430157Z INFO bevy diagnostic: frame_time : 1017.611750ms (avg 149.456476ms) 2024-02-19T15:30:15.430165Z INFO bevy diagnostic: frame_count: 12.000000 (avg 6.000000) ``` </details>
msvbg
pushed a commit
to msvbg/bevy
that referenced
this pull request
Feb 26, 2024
# Objective - The `many_lights` example uses a for-loop around `commands.spawn`. - It is generally recommended to use `spawn_batch` instead to lazily spawn entities, because it doesn't massively grow the command queue. ## Solution - Use `spawn_batch` in `many_lights` example. --- ## Discussion - `thread_rng` is called for each light spawned. This is a simple thread-local `Rc` clone, so it should compile down to a copy and an increment + decrement instruction. - I created `golden_ration` outside of the closure and `move`d it in. This should just be a copy and hopefully will get const-evaluated away. Would it be better to just move it into the closure itself? ## Performance Using `spawn_batch` seems to decrease time-to-first-`Update` by 0.1s: 1.3s to 1.2s. <details> <summary>Raw data and how it was collected.</summary> Before: - 2024-02-19T15:18:57.650987Z to 2024-02-19T15:18:58.912244Z : 1.3 - 2024-02-19T15:19:25.277135Z to 2024-02-19T15:19:26.542092Z : 1.3 - 2024-02-19T15:19:46.841460Z to 2024-02-19T15:19:48.137560Z : 1.3 After: - 2024-02-19T15:17:05.749521Z to 2024-02-19T15:17:06.993221Z : 1.2 - 2024-02-19T15:17:38.153049Z to 2024-02-19T15:17:39.393760Z : 1.2 - 2024-02-19T15:18:10.691562Z to 2024-02-19T15:18:11.891430Z : 1.2 To time performance, I tracked the time from the first `Startup` logged message to the first `Update` logged message. ```shell $ cargo run --release --example many_lights Compiling bevy v0.13.0 (/Users/bdeep/dev/bevy/bevy) Finished release [optimized] target(s) in 1.54s Running `target/release/examples/many_lights` # THIS TIME 2024-02-19T15:30:13.429609Z INFO bevy_render::renderer: AdapterInfo { name: "Apple M1", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal } 2024-02-19T15:30:13.566856Z INFO bevy_winit::system: Creating new window "many_lights" (0v1) 2024-02-19T15:30:13.592371Z WARN many_lights: This is a stress test used to push Bevy to its limit and debug performance issues. It is not representative of an actual game. It must be run in release mode using --release or it will be very slow. 2024-02-19T15:30:13.592572Z INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "MacOS 14.2.1 ", kernel: "23.2.0", cpu: "Apple M1", core_count: "8", memory: "16.0 GiB" } # TO THIS TIME 2024-02-19T15:30:15.429900Z INFO many_lights: Lights: 100000 2024-02-19T15:30:15.430139Z INFO bevy diagnostic: fps : 0.982693 (avg 43.026557) 2024-02-19T15:30:15.430157Z INFO bevy diagnostic: frame_time : 1017.611750ms (avg 149.456476ms) 2024-02-19T15:30:15.430165Z INFO bevy diagnostic: frame_count: 12.000000 (avg 6.000000) ``` </details>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-Rendering
Drawing game state to the screen
C-Examples
An addition or correction to our examples
S-Ready-For-Final-Review
This PR has been approved by the community. It's ready for a maintainer to consider merging it
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
many_lights
example uses a for-loop aroundcommands.spawn
.spawn_batch
instead to lazily spawn entities, because it doesn't massively grow the command queue.Solution
spawn_batch
inmany_lights
example.Discussion
thread_rng
is called for each light spawned. This is a simple thread-localRc
clone, so it should compile down to a copy and an increment + decrement instruction.golden_ration
outside of the closure andmove
d it in. This should just be a copy and hopefully will get const-evaluated away. Would it be better to just move it into the closure itself?Performance
Using
spawn_batch
seems to decrease time-to-first-Update
by 0.1s: 1.3s to 1.2s.Raw data and how it was collected.
Before:
After:
To time performance, I tracked the time from the first
Startup
logged message to the firstUpdate
logged message.