Skip to content
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 1 commit into from
Feb 26, 2024

Conversation

BD103
Copy link
Member

@BD103 BD103 commented Feb 19, 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 moved 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:

  • 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.

$ 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)

@BD103 BD103 added A-Rendering Drawing game state to the screen C-Examples An addition or correction to our examples labels Feb 19, 2024
@IceSentry 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
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Feb 26, 2024
Merged via the queue into bevyengine:main with commit fa179ba Feb 26, 2024
27 checks passed
@BD103 BD103 deleted the many-lights-batch branch February 26, 2024 17:04
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants