0.19 Performance Regression

[AlephCubed]

Bevy version

• Original: 0.18.1
• Current: 0.19.0-rc.2

Relevant system information

• Mostly using 1.97.0-nightly (4d1f98451 2026-05-15), but I did briefly test 1.95.0 (f2d3ce0bd 2026-03-21) and the performance was similar.
• M1 MacBook Air (16GB), MacOS Tahoe 26.5.

What's performing poorly?

I went from stable 60fps in both dev and release builds to ~25fps in dev and ~45fps in release.
My project is a voxel engine where meshes are generated from the voxel grid. However, I am taking these measurements when nothing is happening (after the meshes initially load, I have very little code running).

Source code is available here, with a 0.19 branch that just updates and patches deps. The world will not render until the camera is moved for some reason, so press M to lock the cursor and move it a little.

Before and After Traces

I have tried to do some profiling, but I don't really know what I'm looking for. Some regressions that looked notable are:

Name	0.18 (Mean Time)	0.19 RC 2	Diff
schedule{Render}	16.31ms	21.79ms	+5.47ms (+33%)
sub app{RenderExtractApp}	15.49ms	19.71ms	+4.22ms (+27%)
schedule{PostUpdate}	470.52μs	1.63ms	+1.16ms (+245%)
system{prepare_preprocess_bind_groups}	33.28μs	1.03ms	+992.21μs (+2980%)

If anyone has any ideas as to what to look for, I am happy to do more profiling. Otherwise, the full traces are here:

• Before:
  • Tracy
  • Metal HUD performance report
• After:
  • Tracy
  • Metal HUD performance report

I also tried to do a frame capture in XCode, but XCode just crashes.

[laundmo]

Looking at the blame of prepare_preprocess_bind_groups recent changes, i found

• Unpack bins belonging to multidrawable batch sets on the GPU instead of on the CPU. #23481

Comparing the tracy traces seems to back this up as the cause:

Comparing visually since the render graph changes mean the traces don't have the same functions.
The top one is 0.19-rc1 at 28.35ms, the bottom one is 0.18 at 17ms.
Red line added to highlight the delta.

Also note: i chose a frame with both prepare_windows and write_binned_instane_buffers. The initial frames did not have prepare_windows appear/take a considerable amount of time at all, that only happens every ~3 frames after the first ~180 frames. Without prepare_windows the delta is ~16.5ms to ~18.5ms, still not ideal but far less severe.

@pcwalton Do you have any idea what the issue here could be?

@AlephCubed Could you record another 0.19 trace with PresentMode::AutoNoVsync set? (just that, no need to go and try to disable vsync in macos, which enforces it by default afaik). I suspect at some point bevy/wgpu thinks it needs to delay things for vsync, but doing so stacks with macos built-in, then the cycle repeats after ~3 frames. Make sure you record for long enough, as it only seems to happen after a while.

[AlephCubed]

0.19 with PresentMode::AutoNoVsync:

• Tracy
• Metal HUD performance report

Does seem to be an improvement.

[amtep]

I bisected this. I built the debug version for all and I'm using linux. I had a solid 170fps (= my refresh rate) from the 0.18 branch point up to just before commit 894d8d7, when it fell to about 105fps. It climbed back up to about 115fps at the current main.

894d8d7 Unpack bins belonging to multidrawable batch sets on the GPU instead of on the CPU. (#23481)

So this confirms @laundmo 's finding.