-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Add documentation on how to use Tracy and Perfetto #11484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,152 @@ | ||
| .. _doc_sampling_profilers: | ||
|
|
||
| Sampling profilers | ||
| ================== | ||
|
|
||
| Recommended profilers | ||
| --------------------- | ||
|
|
||
| - `VerySleepy <http://www.codersnotes.com/sleepy/>`__ (Windows only) | ||
| - `HotSpot <https://github.com/KDAB/hotspot>`__ (Linux only) | ||
| - `Xcode Instruments <https://developer.apple.com/xcode/>`__ (macOS only) | ||
|
|
||
| These profilers may not be the most powerful or flexible options, but their | ||
| standalone operation and limited feature set tends to make them easier to use. | ||
|
|
||
| Setting up Godot | ||
| ---------------- | ||
|
|
||
| To get useful profiling information, it is **absolutely required** to use a Godot | ||
| build that includes debugging symbols. Official binaries do not include debugging | ||
| symbols, since these would make the download size significantly larger. | ||
|
|
||
| To get profiling data that best matches the production environment (but with debugging symbols), | ||
| you should compile binaries with the ``production=yes debug_symbols=yes`` SCons options. | ||
|
|
||
| It is possible to run a profiler on less optimized builds (e.g. ``target=template_debug`` without LTO), | ||
| but results will naturally be less representative of real world conditions. | ||
|
|
||
| .. warning:: | ||
|
|
||
| Do *not* strip debugging symbols on the binaries using the ``strip`` command | ||
| after compiling the binaries. Otherwise, you will no longer get useful | ||
| profiling information when running a profiler. | ||
|
|
||
| Benchmarking startup/shutdown times | ||
| ----------------------------------- | ||
|
|
||
| If you're looking into optimizing Godot's startup/shutdown performance, | ||
| you can tell the profiler to use the ``--quit`` command line option on the Godot binary. | ||
| This will exit Godot just after it's done starting. | ||
| The ``--quit`` option works with ``--editor``, ``--project-manager``, and | ||
| ``--path <path to project directory>`` (which runs a project directly). | ||
|
|
||
| .. seealso:: | ||
|
|
||
| See :ref:`doc_command_line_tutorial` for more command line arguments | ||
| supported by Godot. | ||
|
|
||
| Profiler-specific instructions | ||
| ------------------------------ | ||
|
|
||
| VerySleepy | ||
| ~~~~~~~~~~ | ||
|
|
||
| - Start the Godot editor or your project first. | ||
| If you start the Project Manager, make sure to edit or run a project first. | ||
| Otherwise, the profiler will not track the child process since the Project Manager | ||
| will spawn a child process for every project edited or run. | ||
| - Open VerySleepy and select the Godot executable in the list of processes on the left: | ||
|
|
||
| .. image:: img/cpp_profiler_verysleepy_select_process.png | ||
|
|
||
| - Click the **Profile All** button on the right to start profiling. | ||
| - Perform the actions you wish to profile in the editor or project. When you're done, click **Stop** (*not* Abort). | ||
| - Wait for the results window to appear. | ||
| - Once the results window appears, filter the view to remove external modules (such as the graphics driver). | ||
| You can filter by module by finding a line whose **Module** matches the Godot | ||
| executable name, right-clicking that line then choosing | ||
| **Filter Module to <Godot executable name>** in the dropdown that appears. | ||
| - Your results window should now look something like this: | ||
|
|
||
| .. image:: img/cpp_profiler_verysleepy_results_filtered.png | ||
|
|
||
| HotSpot | ||
| ~~~~~~~ | ||
|
|
||
| - Open HotSpot. Click **Record Data**: | ||
|
|
||
| .. image:: img/cpp_profiler_hotspot_welcome.png | ||
|
|
||
| - In the next window, specify the path to the Godot binary that includes debug symbols. | ||
| - Specify command line arguments to run a specific project, with or without the editor. | ||
| - The path to the working directory can be anything if an absolute path is used | ||
| for the ``--path`` command line argument. Otherwise, it must be set so that | ||
| the relative path to the project is valid. | ||
| - Make sure **Elevate Privileges** is checked if you have administrative privileges. | ||
| While not essential for profiling Godot, this will ensure all events can be captured. | ||
| Otherwise, some events may be missing from the capture. | ||
| Your settings should now look something like this: | ||
|
|
||
| .. image:: img/cpp_profiler_hotspot_record.png | ||
|
|
||
| - Click **Start Recording** and perform the actions you wish to profile in the editor/project. | ||
| - Quit the editor/project normally or use the **Stop Profiling** button in HotSpot | ||
| to stop profiling early. Stopping profiling early can result in cleaner profiles | ||
| if you're not interested in the engine's shutdown procedure. | ||
| - Click **View Results** and wait for the profiling visualization to be generated: | ||
|
|
||
| .. image:: img/cpp_profiler_hotspot_view_results.png | ||
|
|
||
| - Use the tabs at the top to navigate between the different views. These views | ||
| show the same data, but in different ways. The **Flame Graph** tab is a good | ||
| way to see which functions take up the most time at a glance. These functions | ||
| are therefore the most important ones to optimize, since optimizing them will | ||
| improve performance the most. | ||
| - At the bottom of all tabs except **Summary**, you will also see a list of CPU threads | ||
| started by the engine along with the CPU utilization for each thread. | ||
| This lets you see threads that can be a bottleneck at a given point in time. | ||
|
|
||
| .. image:: img/cpp_profiler_hotspot_flame_graph.png | ||
|
|
||
| .. note:: | ||
|
|
||
| If you don't want the startup procedure to be included in the profile, you | ||
| can also attach HotSpot to a running process by clicking **Record Data** | ||
| then setting the **Launch Application** dropdown option to **Attach To | ||
| Process(es)**. | ||
|
|
||
| This process attachment-based workflow is similar to the one used by VerySleepy. | ||
|
|
||
| Xcode Instruments | ||
| ~~~~~~~~~~~~~~~~~ | ||
|
|
||
| - Open Xcode. Select **Open Developer Tool** - **Instruments** from the **Xcode** app menu: | ||
| - Double-click on **Time Profiler** in the **Instruments** window: | ||
|
|
||
| .. image:: img/cpp_profiler_xcode_menu.png | ||
|
|
||
| - In the Time Profiler window, click on the **Target** menu, select **Choose target...** | ||
| and specify the path to the Godot binary, command line arguments, and environment variables | ||
| in the next window. | ||
|
|
||
| .. image:: img/cpp_profiler_time_profiler.png | ||
|
|
||
| - You can also attach the Time Profiler to a running process by selecting it from the **Target** | ||
| menu. | ||
|
|
||
| - Click the **Start an immediate mode recording** button to start profiling. | ||
|
|
||
| .. image:: img/cpp_profiler_time_profiler_record.png | ||
|
|
||
| - Perform the actions you wish to profile in the editor or project. When you're done, | ||
| click the **Stop** button. | ||
|
|
||
| - Wait for the results to appear. | ||
| - At the bottom of the window you will see a call tree for all CPU threads started, and | ||
| the **Heaviest Stack Trace** overview. | ||
| - Select **Hide system libraries** in the **Call Tree** menu (at the bottom of the window) to | ||
| remove external modules. | ||
| - You can use the timeline at the top of the window to display details for the specific time period. | ||
|
|
||
| .. image:: img/cpp_profiler_time_profiler_result.png |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,227 @@ | ||
| .. _doc_tracing_profilers: | ||
|
|
||
| Tracing Profilers | ||
| ================= | ||
|
|
||
| Godot currently supports two tracing profilers: | ||
| `Tracy <https://github.com/wolfpld/tracy>`__ and `Perfetto <https://perfetto.dev>`__. | ||
|
|
||
| In order to use either of them, you'll need to build the engine from source. | ||
| If you've never done this before, please read | ||
| :ref:`these docs <doc_compiling_index>` for the platform you want to profile on. | ||
| You'll need to perform the same steps here, but with the addition of a single | ||
| extra argument for ``scons``. | ||
|
|
||
| .. _doc_tracy_profiler: | ||
|
|
||
| Tracy for Windows, Linux, and macOS | ||
| ----------------------------------- | ||
|
|
||
| Tracy is an Open Source profiler that runs on a wide variety of platforms, | ||
| including Windows, Linux, and macOS. While it is primarily a tracing profiler, | ||
| it can also periodically sample data like a | ||
| :ref:`sampling profiler <doc_sampling_profilers>`, giving some of the benefits | ||
| of both approaches. | ||
|
|
||
| Build Godot with Tracy support | ||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| First, clone the latest version of the Tracy source code ("0.13.0" at the | ||
| time of writing) using Git: | ||
|
|
||
| .. code-block:: shell | ||
| git clone -b v0.13.0 --single-branch https://github.com/wolfpld/tracy.git | ||
| This will create a ``tracy`` directory - you can place this anywhere. | ||
|
|
||
| Next, build the release templates for your platform using ``scons``, but adding | ||
| the ``profiler_path=path/to/tracy`` argument with the real path to the ``tracy`` | ||
| directory, as well as ``debug_symbols=yes`` to allow Tracy's sampling features | ||
| to work. | ||
|
|
||
| .. note:: | ||
|
|
||
| You don't have to build release templates, you could also build debug | ||
| templates, or even the editor. However, it's generally recommended to | ||
| profile release templates, because that is the version your players will | ||
| use, and it will perform differently than other types of builds. | ||
|
|
||
| For example, to build release templates for Windows: | ||
|
|
||
| .. code-block:: shell | ||
| scons platform=windows target=template_release debug_symbols=yes profiler_path=path/to/tracy | ||
| Get the Tracy "server" | ||
| ~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| In Tracy terminology, the application you are profiling is the "client", and | ||
| the one receiving the data is the "server". | ||
|
|
||
| If you are on Windows, you can download a pre-built ``tracy-profiler.exe`` | ||
| from the Tracy `releases page <https://github.com/wolfpld/tracy/releases>`_. | ||
|
|
||
| However, if you're on Linux or macOS, you'll either need to find a pre-built | ||
| binary from a package manager (like ``brew`` or ``nix``), or build it from | ||
| source yourself. | ||
|
|
||
| .. note:: | ||
|
|
||
| If you do use a pre-built binary, be sure to use the same version that | ||
| you used when building Godot. | ||
|
|
||
| Build the Tracy server from source | ||
| ++++++++++++++++++++++++++++++++++ | ||
|
|
||
| The full details can be found in the | ||
| `Tracy manual <https://github.com/wolfpld/tracy/releases/latest/download/tracy.pdf>`_, | ||
| but here is the TL;DR: | ||
|
|
||
| .. code-block:: shell | ||
| # On Linux, Tracy uses Wayland by default, so if you use X11 add -DLEGACY=1 | ||
| cmake -B profiler/build -S profiler -DCMAKE_BUILD_TYPE=Release | ||
| cmake --build profiler/build --config Release --parallel | ||
| Record a trace | ||
| ~~~~~~~~~~~~~~ | ||
|
|
||
| Launch the Tracy server - you'll see something like this: | ||
|
|
||
| .. image:: img/cpp_profiler_tracy_start.webp | ||
|
|
||
| If you press "Connect" now, you can profile the launch of Godot. However, | ||
| if you want to profile something specific (for example, a part of your game | ||
| that is exhibiting performance issues), wait before pressing the button. | ||
|
|
||
| Now, export your game using the release templates you built above, and run it. | ||
| As soon as the both the game are running, and you have pressed the "Connect" | ||
| button in Tracy, you'll see data coming in: | ||
|
|
||
| .. image:: img/cpp_profiler_tracy_recording.webp | ||
|
|
||
| When you think you've gathered enough data, press the "Stop" button. If you | ||
| clicked somewhere and the box with the "Stop" button disappeared, you can | ||
| click the top-left most icon to bring it back. | ||
|
|
||
| Examining the trace | ||
| ~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| Here are some of the basic controls: | ||
|
|
||
| - Zoom in/out with the mouse wheel | ||
| - Right click and drag to move forward/backward on the timeline | ||
| - In the top bar, click the left and right arrow buttons by "Frames" to move a single frame on the timeline | ||
|
|
||
| To learn more, see the | ||
| `Tracy manual <https://github.com/wolfpld/tracy/releases/latest/download/tracy.pdf>`_. | ||
|
|
||
| Perfetto for Android | ||
| -------------------- | ||
|
|
||
| Perfetto is the default tracing system for Android. In fact, its system tracing | ||
| service has been built into the platform since Android 9. | ||
|
|
||
| Build Godot with Perfetto support | ||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| First, clone the latest version of the Perfetto source code ("53.0" at the | ||
| time of writing) using Git: | ||
|
|
||
| .. code-block:: shell | ||
| git clone -b v53.0 --single-branch https://github.com/google/perfetto.git | ||
| This will create a ``perfetto`` directory - you can place this anywhere. | ||
|
|
||
| Next, build the Android debug or release templates for your architecture using | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are debug symbols not required for Perfetto?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope! Debug symbols are not required for Perfetto, or Tracy either, if you just use its tracing stuff and not its sampling features |
||
| ``scons`` (per :ref:`Compiling for Android <doc_compiling_for_android>`), but | ||
| adding the ``profiler_path=path/to/perfetto`` argument with the real path to | ||
| the ``perfetto`` directory. | ||
|
|
||
| .. note:: | ||
|
|
||
| It's generally recommended to profile release templates, because that is | ||
| the version your players will use, and it will perform differently than | ||
| other types of builds. However, in the case of Android, it can sometimes | ||
| be useful to use debug templates, because Godot can only do remote | ||
| debugging of games exported from debug templates. | ||
|
|
||
| For example, to build the release templates for arm64: | ||
|
|
||
| .. code-block:: shell | ||
| scons platform=android target=template_release arch=arm64 generate_android_binaries=yes profiler_path=path/to/perfetto | ||
| Configuration | ||
| ~~~~~~~~~~~~~ | ||
|
|
||
| Perfetto requires a configuration file to tell it which events to track. | ||
|
|
||
| Create a file called ``godot.config`` inside of the ``perfetto`` directory | ||
| with this content: | ||
|
|
||
| .. code-block:: text | ||
| # Trace for 10 seconds. | ||
| duration_ms: 10000 | ||
| buffers { | ||
| size_kb: 32768 | ||
| fill_policy: RING_BUFFER | ||
| } | ||
| # Write to file once every second to prevent overflowing the buffer. | ||
| write_into_file: true | ||
| file_write_period_ms: 1000 | ||
| # Track events in the "godot" category. | ||
| data_sources { | ||
| config { | ||
| name: "track_event" | ||
| track_event_config { | ||
| enabled_categories: "godot" | ||
| } | ||
| } | ||
| } | ||
| Record a trace | ||
| ~~~~~~~~~~~~~~ | ||
|
|
||
| Finally, launch your game on an Android device using the export templates you | ||
| built earlier. | ||
|
|
||
| When you're ready to record a trace (for example, when you've hit the part of | ||
| your game that is exhibiting performance issues), you can use this script that | ||
| comes with the Perfetto source code: | ||
|
|
||
| .. code-block:: shell | ||
| cd perfetto | ||
| ./tools/record_android_trace -c godot.config | ||
| This will record for 10 seconds (per the configuration), or until you press | ||
| :kbd:`Ctrl + C`. | ||
|
|
||
| Examining the trace | ||
| ~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| As soon as that script exits, it will launch the Perfetto UI in a web browser. | ||
|
|
||
| To see the Godot events, expand the row for your application by clicking on its | ||
| Android "Unique Name" (Perfetto will also include some events from system | ||
| services in the trace). | ||
|
|
||
| .. image:: img/cpp_profiler_perfetto.webp | ||
|
|
||
| Then you can use the ``WASD`` keys to navigate the graph: | ||
|
|
||
| - Press :kbd:`A` or :kbd:`D` to navigate forward or backward along the timeline | ||
| - Press :kbd:`W` or :kbd:`S` to zoom in or out | ||
|
|
||
| You'll probably need to zoom a bit before you're able to see the individual | ||
| events from Godot. | ||
|
|
||
| To learn more, see the | ||
| `Perfetto UI documentation <https://perfetto.dev/docs/visualization/perfetto-ui>`_. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth including that it supports Win/Mac/Linux as well.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the way Godot has integrated it (at least so far) really supports Windows and Mac. It's setup to use the "system" backend, which requires connecting with Perfetto's system daemon which I think is only Linux and Android. If we added support for the "in process" backend we could add docs for how to use that later? The steps for using it would be somewhat different