Skip to content

Profiling Godot engine (native code) with dotTrace or JetBrains Rider

Jump to bottom
Ivan Skorikov edited this page Oct 21, 2024 · 7 revisions

The following instruction is Windows-only. Native profiling in JetBrains dotTrace and Rider is currently Windows-only.

For this guide, I have in mind a case when there is some code, which is slowing down the main thread. For the example I have put a heavy code inside the _input method in GDScript. However it doesn't matter, which bindings were used GDScript, C#, Rust or any other. This guide is intended to cover a use-case when using the Godot GDScript profiler is not enough and you need to see what is happening in the native code of the engine.

  1. Follow the Godot docs to compile the engine from source and generate sln file. Alternatively, you may use un-official builds with native symbols linked here

  2. Open sln in Rider

  3. Run the Game. It doesn't matter how. I was using the run-configuration in Rider. You may make a copy of auto-generated run-configuration and customize it to directly run the Game.

image
  1. Run -> Profile running process
image
  1. Type godot and select the game process
image

  1. Open the snapshot

  2. Select "Main Thread"

image

Expand the tree until realizing which operation took time. image

In this case, there is some heavy code inside the _input method in GDScript image

Please let me know, what you think about this instruction and the JetBrains native profiling in here.

Minor dotTrace requests which I filed, while preparing this doc:

  • DTRC-31337 Navigation from the native profiling snapshot doesn't work
  • DTRC-31338 Attempt to open snapshot in a Standalone dotTrace
  • DTRC-31336 Change Standalone path automatically changes working dir
  • DTRC-31341 Main thread should be the first one (Rider integration)
  • DTRC-31342 DPA: enable per run-configuration
  • DTRC-31343 DPA: Filterning doesn't work for native code
  • DTRC-31344 Run->"Profile running process" usability
Clone this wiki locally