Performance questions

[miketwenty1]

https://github.com/miketwenty1/wonder15/blob/parentworkingattempt/src/main.rs

A few questions / concerns I have with performance.
I left some questions/comments in code as well.

1. Why does performance get worse the more I use the game, even though it seems entity count is kept under control and I'm despawning aggressively. Even when I decide to zoom all the way in, and move around it is laggy compared to starting a fresh run.
2. Why does zooming in not effect lag? It seems if I zoom out sometimes the performance actually gets better. I would expect zooming all the way in, would help lag because there's less tiles to render.
3. If I toggle the Tile Text with "T", it seems that it does help a little, but only if I spawn the tiles originally without Text. if I were to spawn many tiles with Text and then toggle it off, then the performance gets much worse or can even freeze the game.
4. I'm confused why despawning the Map and the Tiles under the same despawn range condition would panic the game. You can see I put in a hacky "* 2.0" for despawn range of the map to avoid panics. (It seems if I ever despawn a map and then try to despawn the tiles, I'll panic).
5. I'm getting a lot of Entity xxxxx with the InheritedVisibility component has a parent without InheritedVisibility WARNs and I'm not really sure how to address these.

Note if you run this: Q/E expand or contract the despawn range. WASD is moving, Z/X is zoom. T is toggling text. This game is intended for only web. I've set the project so if you want to run it, you can do a cargo install wasm-server-runner and then a cargo run --target wasm32-unknown-unknown
The issues are happen much faster and are more easy to identify when pressing and holding Q for a few seconds to increase the despawn range.

[rparrett]

I think this could be potentially related to one or more of your numbered questions, but it seems that you are despawning all tiles when despawning out-of-range chunks, not just those associated with that particular chunk.

You can iterate through TileStorage to get Entitys associated with the particular Tilemap that is being despawned

for maybe_entity in tile_storage.iter_mut() {
    if let Some(entity) = maybe_entity.take() {
        commands.entity(entity).despawn_recursive();
    }
}

or make your tiles children of the tilemap so that they are despawned when you use despawn_recursive for the tilemap.

Expand Code

diff --git a/src/main.rs b/src/main.rs
index f49eebb..f1e240a 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -45,14 +45,10 @@ fn spawn_chunk(
 ) {
     let tilemap_entity = commands.spawn_empty().id();
     let mut tile_storage = TileStorage::empty(CHUNK_SIZE.into());
+    let mut tile_entities = Vec::with_capacity(CHUNK_SIZE.x as usize * CHUNK_SIZE.y as usize);
     let mut random = rand::thread_rng();
     for x in 0..CHUNK_SIZE.x {
         for y in 0..CHUNK_SIZE.y {
-            let map_transform = Transform::from_translation(Vec3::new(
-                chunk_pos.x as f32 * CHUNK_SIZE.x as f32 * (TILE_SIZE.x),
-                chunk_pos.y as f32 * CHUNK_SIZE.y as f32 * (TILE_SIZE.y),
-                0.0,
-            ));
             total.0 += 1;
             if total.0 % 1_000 == 0 {
                 info!("total: {:?}", total);
@@ -62,7 +58,6 @@ fn spawn_chunk(
             let grid_size = TilemapGridSize { x: 32.0, y: 32.0 };
             let map_type = TilemapType::Square;
             let tile_center = tile_pos.center_in_world(&grid_size, &map_type).extend(1.0);
-            let transform = map_transform * Transform::from_translation(tile_center);
 
             let tile_entity = commands
                 .spawn((
@@ -73,7 +68,7 @@ fn spawn_chunk(
                         ..Default::default()
                     },
                     YoTile,
-                    transform,
+                    Transform::from_translation(tile_center),
                 ))
                 .with_children(|parent| {
                     let ulam_v = ulam::get_value_from_xy(
@@ -102,6 +97,7 @@ fn spawn_chunk(
                 })
                 .id();
             tile_storage.set(&tile_pos, tile_entity);
+            tile_entities.push(tile_entity);
         }
     }
 
@@ -112,23 +108,26 @@ fn spawn_chunk(
     ));
 
     let texture_handle: Handle<Image> = asset_server.load("spritesheet/ss-land-v12.png");
-    commands.entity(tilemap_entity).insert((
-        TilemapBundle {
-            grid_size: TilemapGridSize { x: 32.0, y: 32.0 },
-            size: CHUNK_SIZE.into(),
-            storage: tile_storage,
-            texture: TilemapTexture::Single(texture_handle),
-            tile_size: TILE_SIZE,
-            spacing: TilemapSpacing { x: 2.0, y: 2.0 },
-            transform,
-            render_settings: TilemapRenderSettings {
-                render_chunk_size: RENDER_CHUNK_SIZE,
+    commands
+        .entity(tilemap_entity)
+        .insert((
+            TilemapBundle {
+                grid_size: TilemapGridSize { x: 32.0, y: 32.0 },
+                size: CHUNK_SIZE.into(),
+                storage: tile_storage,
+                texture: TilemapTexture::Single(texture_handle),
+                tile_size: TILE_SIZE,
+                spacing: TilemapSpacing { x: 2.0, y: 2.0 },
+                transform,
+                render_settings: TilemapRenderSettings {
+                    render_chunk_size: RENDER_CHUNK_SIZE,
+                    ..Default::default()
+                },
                 ..Default::default()
             },
-            ..Default::default()
-        },
-        YoMap,
-    ));
+            YoMap,
+        ))
+        .add_children(&tile_entities);
 }
 
 fn startup(mut commands: Commands) {
@@ -196,27 +195,14 @@ fn despawn_outofrange_chunks(
     mut commands: Commands,
     camera_query: Query<&Transform, With<Camera>>,
     chunks_query_map: Query<(Entity, &Transform), With<YoMap>>,
-    chunks_query_tiles: Query<(Entity, &Transform), (Without<YoMap>, With<YoTile>)>,
     mut chunk_manager: ResMut<ChunkManager>,
     despawn_range: Res<DespawnRange>,
 ) {
     for camera_transform in camera_query.iter() {
-        // despawning tiles
-        for (entity, chunk_transform) in chunks_query_tiles.iter() {
-            let chunk_pos = chunk_transform.translation.xy();
-            let distance = camera_transform.translation.xy().distance(chunk_pos);
-            if distance > despawn_range.0 {
-                let x = (chunk_pos.x / (CHUNK_SIZE.x as f32 * TILE_SIZE.x)).floor() as i32;
-                let y = (chunk_pos.y / (CHUNK_SIZE.y as f32 * TILE_SIZE.y)).floor() as i32;
-                chunk_manager.spawned_chunks.remove(&IVec2::new(x, y));
-                commands.entity(entity).despawn_recursive();
-            }
-        }
-        // despawning map with * 2.0 range to avoid panics
         for (entity, chunk_transform) in chunks_query_map.iter() {
             let chunk_pos = chunk_transform.translation.xy();
             let distance = camera_transform.translation.xy().distance(chunk_pos);
-            if distance > despawn_range.0 * 2.0 {
+            if distance > despawn_range.0 {
                 let x = (chunk_pos.x / (CHUNK_SIZE.x as f32 * TILE_SIZE.x)).floor() as i32;
                 let y = (chunk_pos.y / (CHUNK_SIZE.y as f32 * TILE_SIZE.y)).floor() as i32;

1. Why does performance get worse the more I use the game

That seems like a bit of a mystery. I would suggest doing some profiling. The "tracy" profiler makes it pretty easy to log a trace and compare statistics from one portion of a trace to another.

3. Text Toggling

Bevy 0.15 came with a major regression to Text2d performance, but the behavior you're seeing where performance is worse when the text is made invisible is really interesting. I suspect that a recent patch in Bevy might fix it, but unfortunately it's not backportable to Bevy 0.15.

[rparrett]

I think Text2d just can't be a child of a Tilebundle without causing severe pain?

Maybe, but you can probably add Visibility to the tiles to fix that. (Yeah, strange to have both that and TileVisible).

Adding children of map doesn't seem to cause much harm, however I feel like perf goes down a little for some reason.

This is expected. If there are no children, then Bevy won't do transform propagation from tilemap -> tiles which is expensive, even if nothing is changing.

Note that if you need Transform on your tiles, and also plan on ever moving the tilemaps themselves, then you probably want this transform propagation.

This is all very relevant to #582. The current state of bevy_ecs_tilemap seems really janky when trying to use it with bevy hierarchies. Though some folks are apparently doing it successfully.

I have no idea what I'm looking at though

You may want to disable vsync while tracing, as that can confuse things.

The SpriteSource thing you've identified there is the Text2d perf issue I mentioned earlier.

I was personally most interested in comparing

• Behavior near the start of the app
• Behavior after moving around a bunch when things seem to get bogged down

From the statistics panel, it's possible to filter the statistics so that they are only calculated for a particular range of frames. So you could drill into the most expensive tracing spans for each of those cases and try to get an idea of what is becoming slow.

[rparrett]

You can also try removing bevy's multi_threaded feature to more closely match what's happening on the web. But I think all the things you mentioned were reproducible on native builds for me.

[miketwenty1]

Maybe, but you can probably add Visibility to the tiles to fix that. (Yeah, strange to have both that and TileVisible).

I added Visibility like this, but I'm not sure if that's what you mean:

 let tile_entity = commands
    .spawn((
        TileBundle {
            position: tile_pos,
            tilemap_id: TilemapId(tilemap_entity),
            texture_index: TileTextureIndex(num),
            ..Default::default()
        },
        Visibility::Visible, //here
        YoTile,
        Transform::from_translation(tile_center),
    ))
    .with_children(|parent| {
   // ...

I'm not really noticing much difference by doing that.

Note that if you need Transform on your tiles, and also plan on ever moving the tilemaps themselves, then you probably want this transform propagation.

I won't need to move/rotate or scale my tiles so it may be best to not make tiles children of maps?

You may want to disable vsync while tracing, as that can confuse things.

I'm not really sure how to disable "vsync". Is this a computer hardware thing or a tracy setting? I'm using MacOS.

Behavior near the start of the app

Mostly green/yellow bars for the frames then as I start to spawn in more tiles with or without text2d I will get red bars.

Behavior after moving around a bunch when things seem to get bogged down

Things slow to a crawl.

you could drill into the most expensive tracing spans for each of those cases and try to get an idea of what is becoming slow.

So something interesting is toggling text on, I'm getting ~430 ms frames (very slow), but with the text off, I'm getting even slower frames closer to ~500ms (even slower!).

~500ms screenshot of game and tracy screenshot with text toggled OFF / Visibility::Hidden with "T"

~430ms screenshot of game and tracy screenshot with text toggled ON / Visibility::Visible with "T"

In terms of drilling in, I assume you mean the 4 rendering zone names at the bottom of the frames?

If so, I'm not really sure what to do with this info even after drilling in, I can see the execution time for system_commands{name="bevy_render::extract_component::extract_components<bevy_sprite::SpriteSource>"} is 448ms which seems bad for a single frame. But I'm not sure what is actionable on that.

You can also try removing bevy's multi_threaded feature to more closely match what's happening on the web. But I think all the things you mentioned were reproducible on native builds for me.

Yes all native builds and wasm builds are expediting similar behavior. I'm no longer messing with wasm currently for tracy reasons, but that will be the final target after I figure out a method to what I want to do.

[rparrett]

I added Visibility like this, but I'm not sure if that's what you mean:

Yep

I'm not really noticing much difference by doing that.

Sorry, I meant that in response to the InheritedVisibility warnings. Bevy doesn't like having "gaps" in these propagated properties. Anything with a parent that has Visibility should also have it.

SpriteSource ... But I'm not sure what is actionable on that.

This is not actionable, except to fix it in Bevy. Having a bunch of Text2d whether it is visible or not is just very slow in Bevy 0.15 and it seems like it's not going to get fixed until 0.16 unless a clever and motivated person figures something out.

I'm not really sure how to disable "vsync". Is this a computer hardware thing or a tracy setting? I'm using MacOS.

Add present_mode: PresentMode::AutoNoVsync to your window. This isn't necessary, but the time bevy/wgpu spend waiting for vertical sync ends up in a random "prepare" span and it can be confusing and muddy the stats.

Mostly green/yellow bars for the frames then as I start to spawn in more tiles with or without text2d I will get red bars.
Things slow to a crawl.

Yeah, sorry, I am trying to say that comparing statistics from tracy for the periods of time when the app is behaving like that could be interesting. You want to know why it is slowing to a crawl. So find out what is going on during that time period that is different from before.

[miketwenty1]

Sorry, I meant that in response to the InheritedVisibility warnings

Ohh nice!

Add present_mode: PresentMode::AutoNoVsync to your window

Cool I added present_mode: bevy::window::PresentMode::AutoNoVsync, to my window within DefaultPlugins

Yeah, sorry, I am trying to say that comparing statistics from tracy for the periods of time when the app is behaving like that could be interesting. You want to know why it is slowing to a crawl. So find out what is going on during that time period that is different from before.

Here is a screenshot of me trying to use the compare feature on tracy, one uploaded that ended with latency issues compared to a fast current one that hasn't had any movement on it yet. I don't think this is what you're asking for though.

I also was able to zero in on a single "zone"? "system_commands{name="bevy_render::extract_component::extract_visible_components<bevy_ecs_tilemap::render::material::MaterialTilemapHandle<bevy_ecs_tilemap::render::material::StandardTilemapMaterial>>"}

It's not clear for me how to go about this in a better way, but searching for this zone I'm able to compare the latency screenshots.
8 microseconds (when game is untouched with single chunk loaded)

vs 10 ms with some activity.

Note: I've commented out the Text2d entity spawning/creation for both of these tests. These are both using this commit: https://github.com/miketwenty1/wonder15/tree/1953d88cb061de014ebb49713bd0d26b8d34d3c4

I also have another question. I've enabled the bevy/trace_tracy_memory running as cargo run --release --features bevy/trace_tracy_memory, I noticed I can see a bunch of things marked "error"? Is this normal to see?