GLTF loading and animation performance regression

[aloucks]

Bevy version

main
deb135c

Relevant system information

$ cargo --version -vvv
cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
host: x86_64-pc-windows-msvc
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:Schannel)
os: Windows 10.0.22631 (Windows 11 Professional) [64-bit]

What you did

cargo run --example scene_viewer --features animation assets/models/UndeadMale/scourgemale.gltf

What went wrong

The gltf file never finishes loading when running with the dev profile (or at least it takes a very very long time - I've killed the process after a few minutes). It will eventually load when running it with --release but it's slow and the animation playback is very choppy.

Additional information

The file loads nearly instantly with v0.15.1 and animation playback is smooth, even with the dev profile.

UndeadMale.zip

[rparrett]

Are you able to bisect?

[aloucks]

Are you able to bisect?

The first bad commit is 21f1e30

[rparrett]

This also seems reproducible with many_foxes.

commit	fps
21f1e30~1	300
21f1e30	90

This seems to be mostly from a particular parallel query operation in transform propagation.

par_for_each{query="(bevy_ecs::entity::Entity, &bevy_ecs::hierarchy::Children, bevy_ecs::change_detection::Ref<bevy_transform::components::transform::Transform>, &mut bevy_transform::components::global_transform::GlobalTransform)" filter="bevy_ecs::query::filter::Without<bevy_ecs::hierarchy::Parent>"}

It's possible that profiling the original scene_viewer + undead male repro might yield something else. I haven't tried yet.

edit: Seeing most time spent in the same place with the single undead male.

[cart]

I was able to repo. This is the result of propagating over a million transforms per frame, when prior to #17398 we were propagating 28,000 per frame. We have the same number of transforms on both branches. This is actually caused by Children containing duplicates. I suspect that this is caused by buggy "scene spawn" code that spawns both a fully populated Children collection and a ChildOf, resulting in duplicates. This isn't possible via "normal" Rust flows, as you can't spawn a populated Children collection.

[cart]

Looking at the source, Children is stored in the Scene's World, and the scene spawn logic duplicates that into the main World using FromReflect (which means the full Children are written on insert, bypassing the normal flow and resulting in duplicates).