Why is the bench example so slow?

[feelingsonice]

Why is the bench example so slow despite Frustum Culling enabled? I understand that the map size is 1280 x 1280 but my understanding is that Frustum Culling will only render the tiles that are within the camera's view?

If there's no way around this performance slow down then what's the suggestion for larger maps? Is it to do chunking?

[rparrett]

You may want to do your own profiling, but last time I looked, the following were the main factors. This was some time ago, so my memory might not be totally correct or might be outdated.

• Command application of the initial spawn is slow, but would be faster using spawn_batch. See fill_tilemap_* can use spawn_batch for improved performance  #300. I think that someone is working on command batching in Bevy which would also help.
• Visibility / transform propagation in Bevy is expensive and computed every frame even if nothing changes. I think thatbevy_ecs_tilemap utilizes visibility propagation, but not transform propagation. It's also slightly handy for despawing a particular tilemap. If you don't need that, don't spawn the tiles as a child of the tilemap.
• There is overhead in bevy for entities just existing, even if they aren't rendered, because for (complicated technical reasons I don't understand) space for entities must be reserved in the render world regardless.

[feelingsonice]

Iiuc, bevy_ecs_tilemap is using a custom renderer? Would you happen to know the performance gain of bevy_ecs_tilemap compare to using native the spritesheet atlas? Essentially, every tile in my tilemap is different so I can't call fill_tilemap_*, in which case, is there still any major performance gain as compared to managing my own tilemap using the native asset loader?

[rparrett]

Essentially, every tile in my tilemap is different so I can't call fill_tilemap_*, in which case is there still any major performance gain

Absolutely, yes. fill_tilemap_* are mostly just convenience functions for our examples, really.

There is a custom chunking renderer. Even though every tile is an entity, they aren't "rendered entities."

If I recall correctly, perf vs. naively spawning a bunch of sprites is quite good I want to say ~2x?, unless your tiles are in a bevy hierarchy. But Bevy's sprite renderer has had some upgrades recently and I don't think things have been benchmarked since then.