Profiling support

[Vrixyz]

This PR uses https://crates.io/crates/profiling so we can choose any supported profiling options. This is also helpful for users to get an understanding of performances.

• Blocked by Expose UI options EmbarkStudios/puffin#235

using tracy on all_examples3 (cargo run --bin all_examples3 --features profiling/profile-with-tracy)

Should we remove counters from rapier ? I imagine it would be great to be able to output the same kind of csv we're doing currently, but using this profiling option.

[Vrixyz]

I added the profiling dependency there but I think I didn´t mark any functions

[Vrixyz]

profiling::finish_frame!(); belongs here (in user code), as rapier isn't strictly the owner of the loop.

[sebcrozet]

This is looking great, thank you! A few remarks:

• Does #[profiling::function] generate code or slow down compilation when no backend is specified? If that’s the case, then profiling should be behind a feature.
• The flamegraph is expanding vertically a lot with empty space. Can the vertical size be constrained?
• The table is also quite big vertically, it would be nice if it was smaller.
• On the testbed, we should remove from the flamegraph and table anything that isn’t related to rapier (like all the wgpu stuffs).

Let’s keep the rapier counters for now, until I get more familiar with this new profiling tool.

[Vrixyz]

• Does #[profiling::function] generate code or slow down compilation when no backend is specified? If that’s the case, then profiling should be behind a feature.

No runtime impact should appear: from their docs :

• "If the end-user of your library doesn't use profiling, the macros in this crate will emit no code at all.

Concerning compilation time, I didn't notice impact.

See attached compiling timings differences from this branch (without profiling enabled) with master:

timings_profiling_vs_no_profiling.zip

[Vrixyz]

• The flamegraph is expanding vertically a lot with empty space. Can the vertical size be constrained?
• The table is also quite big vertically, it would be nice if it was smaller.
• On the testbed, we should remove from the flamegraph and table anything that isn’t related to rapier (like all the wgpu stuffs).

I imagine the best solution would be to filter performance information, unfortunately it's complicated to make on egui_puffin:

I can imagine a solution by providing an automatic zoom into our relevant time span, by finding harness::step_with_graphics scope id, then retrieving its scope data from its stream, like it's done for the built-in UI.

Figuring this out is not trivial and it would not support selecting multiple frames.

Strictly removing data from wgpu etc doesn't seem supported by profiling nor egui_puffin.

As an ideal solution would require potentially controversial PR to puffin_egui, I settled for a simple approach, with a default filter to puffin_egui, which highlights our rapier specific profiling data. This needs user manual zoom.

I removed some function profiling markers to help with information overload.

adapting the egui render of the puffing profiler is not trivial either, so I shoved it into its own window, which is collapsed by default:

• Note this still needs a puffin_egui modification: Expose UI options EmbarkStudios/puffin#235

[sebcrozet]

Not sure if I’m missing something but I’m not seeing any profiling now:

Note that I modified the cargo patches to use the git dependency to your branch expose_ui_options for puffin_egui.

[sebcrozet]

Thanks!
I don’t know when puffin will merge your changes. So I think that in the mean time we move the changes needing the cargo patches behind a feature (#[unstable-puffin-pr-235) so we can use it locally without blocking our capability to publish the testbed.

[sebcrozet]

Suggested change

	# puffin_egui = { optional = true, path = "../puffin/puffin_egui" }
	# puffin = { optional = true, path = "../puffin/puffin" }

[Vrixyz]

outside the scope of this PR, but running the testbed in AutoNoVsync mode is interesting to get less visual noise about wgpu :

But this would probably need some adaptation to the loop to avoid being a strict fixed timestep each draw calls: currently: higher FPS means faster simulation speed.

[Vrixyz]

add comment to explain the patch needed