mirror of
https://github.com/bevyengine/bevy
synced 2024-11-10 07:04:33 +00:00
fa179ba475
# 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>
|
||
|---|---|---|
| .. | ||
| bevymark.rs | ||
| many_animated_sprites.rs | ||
| many_buttons.rs | ||
| many_cubes.rs | ||
| many_foxes.rs | ||
| many_gizmos.rs | ||
| many_glyphs.rs | ||
| many_lights.rs | ||
| many_sprites.rs | ||
| README.md | ||
| text_pipeline.rs | ||
| transform_hierarchy.rs | ||
| warning_string.txt | ||
Stress tests
These examples are used to stress test Bevy's performance in various ways. These should be run with the "stress-test" profile to accurately represent performance in production, otherwise they will run in cargo's default "dev" profile which is very slow.
Example Command
cargo run --profile stress-test --example <EXAMPLE>