sampling_profilers.rst 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152
  1. .. _doc_sampling_profilers:
  2. Sampling profilers
  3. ==================
  4. Recommended profilers
  5. ---------------------
  6. - `VerySleepy <http://www.codersnotes.com/sleepy/>`__ (Windows only)
  7. - `HotSpot <https://github.com/KDAB/hotspot>`__ (Linux only)
  8. - `Xcode Instruments <https://developer.apple.com/xcode/>`__ (macOS only)
  9. These profilers may not be the most powerful or flexible options, but their
  10. standalone operation and limited feature set tends to make them easier to use.
  11. Setting up Godot
  12. ----------------
  13. To get useful profiling information, it is **absolutely required** to use a Godot
  14. build that includes debugging symbols. Official binaries do not include debugging
  15. symbols, since these would make the download size significantly larger.
  16. To get profiling data that best matches the production environment (but with debugging symbols),
  17. you should compile binaries with the ``production=yes debug_symbols=yes`` SCons options.
  18. It is possible to run a profiler on less optimized builds (e.g. ``target=template_debug`` without LTO),
  19. but results will naturally be less representative of real world conditions.
  20. .. warning::
  21. Do *not* strip debugging symbols on the binaries using the ``strip`` command
  22. after compiling the binaries. Otherwise, you will no longer get useful
  23. profiling information when running a profiler.
  24. Benchmarking startup/shutdown times
  25. -----------------------------------
  26. If you're looking into optimizing Godot's startup/shutdown performance,
  27. you can tell the profiler to use the ``--quit`` command line option on the Godot binary.
  28. This will exit Godot just after it's done starting.
  29. The ``--quit`` option works with ``--editor``, ``--project-manager``, and
  30. ``--path <path to project directory>`` (which runs a project directly).
  31. .. seealso::
  32. See :ref:`doc_command_line_tutorial` for more command line arguments
  33. supported by Godot.
  34. Profiler-specific instructions
  35. ------------------------------
  36. VerySleepy
  37. ~~~~~~~~~~
  38. - Start the Godot editor or your project first.
  39. If you start the Project Manager, make sure to edit or run a project first.
  40. Otherwise, the profiler will not track the child process since the Project Manager
  41. will spawn a child process for every project edited or run.
  42. - Open VerySleepy and select the Godot executable in the list of processes on the left:
  43. .. image:: img/cpp_profiler_verysleepy_select_process.png
  44. - Click the **Profile All** button on the right to start profiling.
  45. - Perform the actions you wish to profile in the editor or project. When you're done, click **Stop** (*not* Abort).
  46. - Wait for the results window to appear.
  47. - Once the results window appears, filter the view to remove external modules (such as the graphics driver).
  48. You can filter by module by finding a line whose **Module** matches the Godot
  49. executable name, right-clicking that line then choosing
  50. **Filter Module to <Godot executable name>** in the dropdown that appears.
  51. - Your results window should now look something like this:
  52. .. image:: img/cpp_profiler_verysleepy_results_filtered.png
  53. HotSpot
  54. ~~~~~~~
  55. - Open HotSpot. Click **Record Data**:
  56. .. image:: img/cpp_profiler_hotspot_welcome.png
  57. - In the next window, specify the path to the Godot binary that includes debug symbols.
  58. - Specify command line arguments to run a specific project, with or without the editor.
  59. - The path to the working directory can be anything if an absolute path is used
  60. for the ``--path`` command line argument. Otherwise, it must be set so that
  61. the relative path to the project is valid.
  62. - Make sure **Elevate Privileges** is checked if you have administrative privileges.
  63. While not essential for profiling Godot, this will ensure all events can be captured.
  64. Otherwise, some events may be missing from the capture.
  65. Your settings should now look something like this:
  66. .. image:: img/cpp_profiler_hotspot_record.png
  67. - Click **Start Recording** and perform the actions you wish to profile in the editor/project.
  68. - Quit the editor/project normally or use the **Stop Profiling** button in HotSpot
  69. to stop profiling early. Stopping profiling early can result in cleaner profiles
  70. if you're not interested in the engine's shutdown procedure.
  71. - Click **View Results** and wait for the profiling visualization to be generated:
  72. .. image:: img/cpp_profiler_hotspot_view_results.png
  73. - Use the tabs at the top to navigate between the different views. These views
  74. show the same data, but in different ways. The **Flame Graph** tab is a good
  75. way to see which functions take up the most time at a glance. These functions
  76. are therefore the most important ones to optimize, since optimizing them will
  77. improve performance the most.
  78. - At the bottom of all tabs except **Summary**, you will also see a list of CPU threads
  79. started by the engine along with the CPU utilization for each thread.
  80. This lets you see threads that can be a bottleneck at a given point in time.
  81. .. image:: img/cpp_profiler_hotspot_flame_graph.png
  82. .. note::
  83. If you don't want the startup procedure to be included in the profile, you
  84. can also attach HotSpot to a running process by clicking **Record Data**
  85. then setting the **Launch Application** dropdown option to **Attach To
  86. Process(es)**.
  87. This process attachment-based workflow is similar to the one used by VerySleepy.
  88. Xcode Instruments
  89. ~~~~~~~~~~~~~~~~~
  90. - Open Xcode. Select **Open Developer Tool** - **Instruments** from the **Xcode** app menu:
  91. - Double-click on **Time Profiler** in the **Instruments** window:
  92. .. image:: img/cpp_profiler_xcode_menu.png
  93. - In the Time Profiler window, click on the **Target** menu, select **Choose target...**
  94. and specify the path to the Godot binary, command line arguments, and environment variables
  95. in the next window.
  96. .. image:: img/cpp_profiler_time_profiler.png
  97. - You can also attach the Time Profiler to a running process by selecting it from the **Target**
  98. menu.
  99. - Click the **Start an immediate mode recording** button to start profiling.
  100. .. image:: img/cpp_profiler_time_profiler_record.png
  101. - Perform the actions you wish to profile in the editor or project. When you're done,
  102. click the **Stop** button.
  103. - Wait for the results to appear.
  104. - At the bottom of the window you will see a call tree for all CPU threads started, and
  105. the **Heaviest Stack Trace** overview.
  106. - Select **Hide system libraries** in the **Call Tree** menu (at the bottom of the window) to
  107. remove external modules.
  108. - You can use the timeline at the top of the window to display details for the specific time period.
  109. .. image:: img/cpp_profiler_time_profiler_result.png