8e84b461a0
# Objective - I was getting familiar with the many_components example to test some recent pr's for executor changes and saw some things to improve. ## Solution - Use `insert_by_ids` instead of `insert_by_id`. This reduces the number of archetype moves and improves startup times substantially. - Add a tracing span to `base_system`. I'm not sure why, but tracing spans weren't showing for this system. I think it's something to do with how pipe system works, but need to investigate more. The approach in this pr is a little better than the default span too, since it allows adding the number of entities queried to the span which is not possible with the default system span. - println the number of archetype component id's that are created. This is useful since part of the purpose of this stress test is to test how well the use of FixedBitSet scales in the executor. ## Testing - Ran the example with `cargo run --example many_components -F trace_tracy 1000000` and connected with tracy - Timed the time it took to spawn 1 million entities on main (240 s) vs this pr (15 s) --- ## Showcase  ## Future Work - Currently systems are created with a random set of components and entities are created with a random set of components without any correlation between the randomness. This means that some systems won't match any entities and some entities could not match any systems. It might be better to spawn the entities from the pool of components that match the queries that the systems are using. |
||
|---|---|---|
| .. | ||
| bevymark.rs | ||
| many_animated_sprites.rs | ||
| many_buttons.rs | ||
| many_cameras_lights.rs | ||
| many_components.rs | ||
| many_cubes.rs | ||
| many_foxes.rs | ||
| many_gizmos.rs | ||
| many_glyphs.rs | ||
| many_lights.rs | ||
| many_materials.rs | ||
| many_sprites.rs | ||
| many_text2d.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>