To access the Unity Profiler, go to Window > Analysis > Profiler or use the keyboard shortcut Ctrl+7 (Command+7 on macOS).
The Profiler records multiple areas of your application’s performance, and displays that information to you. You can use this information to make informed decisions about what you might need to optimize in your application, and to confirm that your optimizations produce the results you expect.
The Profiler records and keeps the last 300 frames of your game, and shows you detailed information about every frame. You can inspect script code, and how your application uses certain Assets and resources that might be slowing it down. You can also compare how your application performs on different devices.
The Profiler has several different Profiler modules that you can add to your profiling session to get more information on areas such as rendering, memory, and audio.
This page covers the following topics:
The Profiler window is laid out as follows:
The Profiler controls are in the toolbar at the top of the Profiler window. Use these to start or stop recording profiler data, and to navigate through profiled frames.
Control | Función: | |
---|---|---|
Record | Enable this setting to record profiling information for the active modules when you run your application. If you don’t have this button enabled, the Profiler doesn’t collect any data when you run your application. | |
Deep Profile | Enable this setting to profile all C# methods. When you enable this setting, Unity adds instrumentation to all mono calls, which then allows for a more detailed investigation of your scripts. See Deep Profiling. | |
Profile Editor | Enable this setting to profile the Unity Editor. This displays the resources that the Editor is currently using. Click the button again to stop profiling the Editor. | |
Attach to Player | Select which target to profile your application on. By default, this is set to Editor, which refers to the Unity Editor. Unity also automatically detects any devices that are running on your network or connected via USB, and displays them in the drop-down. Click Enter IP in the drop-down to manually enter the IP address of the device you want to profile your application on. For more information, see Profiling your application. | |
Allocation Callstacks | To record call stacks for scripting memory allocations, click this drop-down and select Managed Allocations. Frames that the Profiler records when you enable this option have information in the GC.Alloc samples on the full call stack that lead to a managed scripting allocation, even when Deep Profile is not active. For more information, see the Allocation Callstacks section of the CPU Usage Profiler module page. | |
Clear on Play | Enable this setting to erase all data from the Profiler window next time you click Play in the Player window, or when you connect to a new target device. | |
Clear | Erase all data from the Profiler window. | |
Load | Load saved Profiler data into the Profiler window. You can also load binary profile data that the Player has written out to file via the Profiler.logFile API. Hold down the Shift button and click the Load button to append the file contents to the current profile frames. |
|
Save | Save the Profiler data into a .data file in your Project folder. | |
Transport controls | Use these controls to navigate around the Profiler charts. If you are profiling in Play mode and you click on any of these transport controls while your application is running, your application pauses. | |
Frame number | Indicates the frame number you are currently looking at in the Profiler. | |
Back arrow | Navigate one frame back. | |
Forward arrow | Navigate one frame forward. | |
Current | Jump to the last recorded frame and make the Profiler display data collected in real time. |
To maintain a low overhead, Unity only redraws every fifth frame of the Editor UI. This results in a slightly stuttered update.
Usually the Profiler only profiles code timings that are explicitly wrapped in ProfilerMarkers. This includes the first call stack depth of invocations from the engine’s native code into your scripting code, such as a MonoBehaviour
’s Start
, Update
, or similar methods.
Without adding more explicit ProfilerMarker
instrumentation to your own code, the only other samples you can see as child samples of your scripting code are those that call back into Unity’s API, if that API has been instrumented. Most API calls that carry a performance overhead are instrumented. For example, accessing the main Camera through the Camera.main
API is registered as a “FindMainCamera
” sample.
When you enable the Deep Profile setting, the Profiler profiles every part of your script code and records all function calls, including at least the first call stack depth into any Unity API. This is useful information to help you work out where your code impacts on your application’s performance, but it comes with a large overhead.
When you deep profile your application, Unity injects profiler instrumentation into all of your script methods to record all function calls. This is useful to understand where your application code spends the most time. Because you need to reload the assembly to use Deep Profiling, you need to start the Players with the -deepprofiling
command line argument.
Deep Profiling is resource-intensive and uses a lot of memory. As a result, your application runs significantly slower while it is profiling. Deep Profiling is better suited for small games with simple scripting. If you are using complex script code, your application might not be able to use Deep Profiling at all, and for many larger applications, Deep Profiling might make Unity run out of memory.
If you run into issues where there are too many samples for the Profiler to store in the ring buffer it uses to stream them to the Profiler, then Unity displays an error message. To increase the size of the ring buffer, you can adjust the Profiler.maxUsedMemory property for the Player you’re profiling.
If Deep Profiling causes the frame rate of your application to drop so much that it is impossible to run, you can manually profile blocks of your script code, which has a smaller overhead than Deep Profiling. Use ProfilerMarkers to manually add the instrumentation you need to mark up script blocks. These appear in the CPU Usage Profiler module.
If you want to find out which call stacks lead to a GC.Alloc sample without Deep Profiling, you can turn on the collection of Allocation Callstacks. When you enable the Managed Allocations setting, you can select the GC.Alloc samples in the Timeline view, or use the Show Related Objects panel in the Hierarchy view to find the call stacks for these samples. For more information, see the documentation on Allocation Callstacks in the CPU Profiler Module page.
Enable Color Blind Mode to make the Profiler use higher contrast colors in its graphs. This enhances visibility for users with red-green color blindness (such as deuteranopia, protanopia, or tritanopia). To enable it, go to the context menu in the upper-right corner of the Profiler window, and select Color Blind Mode.
The top part of the Profiler window is divided into Profiler modules that profile specific areas of your game. When you profile your application, Unity displays the data related to each module in corresponding charts.
The CPU Usage module provides the best overview of how much time your application spends on each frame. The other modules collect more specific data and can help you inspect more specific areas or to monitor the vitals of your application, such as memory consumption, rendering, or audio statistics.
Each module has its own chart. When you select a module, a Module Details panel appears in the bottom section of the window, which you can use to inspect the detailed data the module collects.
Profiler module | Función: |
---|---|
CPU Usage | Displays an overview of where your application spends the most time, in areas such as physics, scripts, animation, and garbage collection. This module contains broad profiling information about your application, and you can use it to decide which further modules to use to investigate more specific issues in your application. This module is always active, even if you close it. See CPU Usage Profiler module |
GPU Usage | Displays information related to graphics processing. By default this module is not active, because it has a high overhead. See GPU Usage Profiler module. |
Rendering | Displays information on how Unity renders graphics in your application, including information on static and dynamic batching, SetPass and Draw calls, triangles, and vertices. See Rendering Profiler module. |
Memory | Displays information on how Unity allocates memory in your application. This is particularly useful for seeing how scripting allocations (GC.Alloc) lead up to garbage collection, or how your application’s Asset memory usage trends over time. See Memory Profiler module. |
Audio | Displays information related to the audio in your application, such as when and how many audio sources play, how much CPU usage the Audio system requires, and how much memory Unity allocates to it. See Audio profiler module. |
Video | Displays information related to video in your application. |
Physics | Displays information about the physics in your application that the physics engine has processed. See Physics Profiler module. |
Physics (2D) | Similar to the Physics Profiler module, this module displays information about where the physics engine has processed 2D physics in your application. |
Network Messages(deprecated) | Displays information about lower level packets and messages sent or received by the Multiplayer high level API. Note: The Multiplayer high level API is deprecated. |
Network Operations (deprecated) | Displays fine-grained information about which types or operations are in the messages sent and received by the Multiplayer high level API, such as how many SyncVars or Commands have been transferred. Note: The Multiplayer high level API is deprecated. |
UI | Displays information about how Unity handles UI batching for your application, including why and how Unity batches items. See UI Profiler module. |
UI Details | Similar to the UI Module, this module’s chart adds data about batch and vertices count, as well as markers which include information about user input events that trigger UI changes. |
Global Illumination | Displays information on how much CPU resource Unity spends on the Global Illumination lighting subsystem in your application. See Global Illumination Profiler window. |
Some Profiler modules have a large data collection overhead, such as the GPU, UI, and Audio Profiler module. To prevent these modules from affecting your application’s performance, you can click the close button (x) in the top right hand corner of the module to deactivate it. This removes the module from the window, stops the Profiler from collecting that module’s data, and lowers the Profiler’s overhead.
This does not apply to the CPU Usage module, which always collects data even when it’s not active, because other modules rely on it.
To add a module, select the Add Profiler dropdown and choose the Profiler you want to activate. When you choose a Profiler module from the drop-down, it starts collecting data, but shows no data for the period in which it was not active.
To avoid the overhead of the GPU Profiler module, it is not active by default. The GPU Profiler module must be active at the start of your application to hook into the graphics driver. If you add it later, it has no effect on most platforms, and the Profiler displays the message “GPU profiling is not supported by the graphics card driver (or it was disabled because of driver bugs)”.
If you instruct the Profiler to collect and send data to disk through the Profiler.logFile API instead of through the Profiler window, you can turn off Profiler modules through Profiler.SetAreaEnabled().
Some settings that debug your scripts through an external IDE might also create overhead. To avoid this overhead and get more accurate measurements, disable the Editor Attaching setting (menu: Preferences > External Tools). Similarly, when you profile build Players, open Build Settings and disable Script Debugging to avoid that overhead.
The upper part of the Profiler window displays performance data over time on a frame-by-frame basis. When you run your application, the Profiler records data for each frame. The Profiler window displays the history of the last 300 frames it profiles. When you click in the Profiler frame chart area of the Profiler window, a white line appears, which highlights one frame of your application. To navigate between frames, use the transport controls in the toolbar of the Profiler window.
Unity manages the vertical scale of the charts automatically, and the charts attempt to fill the vertical space of the window. To see more detail in a chart, you can remove other Profiler modules, or you can drag the splitter between the charts and the detailed statistics area to increase the screen area of the charts.
To toggle hiding and displaying a metric in a chart, click the colored square next to its label in its module. This can be useful to identify the causes of spikes. In stacked charts such as the CPU Usage Profiler’s chart, you can reorder the metric labels to affect the stacking order. This can make the chart clearer, by making the noisier metrics more visible.
Each Profiler module collects different performance data metrics and displays them in separate charts. When you click on a frame, Unity displays more details about the frame in the Module Details pane in the bottom half of the Profiler window. The type of detail in this window changes depending on which Profile module you select. For more information about the specific details that each module displays in this area, see the individual documentation for the Profiler modules.
If you start your built Player or the Unity Editor from the command line (such as the Command Prompt on Windows, Terminal on macOS, Linux shell, or adb for Android), you can pass command line arguments to configure some Profiler settings.
Command line argument | Descripción |
---|---|
-deepprofiling |
Enable Deep Profiling in a built Player. This only works with Players built against the Mono Scripting Backend. |
-profileStartup |
Profile the start-up of a Player or the Editor. When you use this argument with a Player, it has the same effect as building the Player with the Autoconnect Profiler option enabled in Build Settings. When you use this argument with the Editor, it starts collecting and displaying Profiler information in the Profiler window on start-up of the Editor. |
-profiler-maxusedmemory |
By default, maxUsedMemory is 16MB for Players and 256MB for the Editor. You can use this argument to set the maxUsedMemory parameter to a custom size at start-up (for example, -profiler-maxusedmemory 16777216 ). The size is set in bytes. |