Profiler command line arguments
Profiler counters reference
Profiler markers referenceUnityâs code is instrumented with profiler markersPlaced in code to describe a CPU or GPU event that is then displayed in the Unity Profiler window. Added to Unity code by default, or you can use ProfilerMarker API to add your own custom markers. More info
See in Glossary that give you insight into what takes up time in your application. The following tables contain a list of some of the in-built markers.
The main thread base markers provide a clear separation between the time spent on your application and time spent on Unity Editor and ProfilerA window that helps you to optimize your game. It shows how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating, or in your game logic. More info
See in Glossary activities. You can also use these markers with the ProfilerRecorder API to get the timing of a frame on the main thread, or the FrameTimingManager API for high level frame stats at runtime.
You can also use the rendering profiler countersPlaced in code with the ProfilerCounter API to track metrics, such as the number of enemies spawned in your game. More info
See in Glossary CPU Main Thread Frame Time, CPU Render Thread Frame Time, and CPU Total Frame Time to get high-level timings of the CPU usage of your application. For more information, refer to Rendering profiler counters reference.
For more information, refer to Play mode and Edit mode samples.
Profiler.CollectEditorStatsSamples nested under the Profiler.CollectGlobalStats marker indicate how much overhead the Player has when it collects the statistics of a particular module. All other child samples only reflect their effect in the Editor.
To remove the overhead that a particular module has, close the moduleâs chart, or call Profiler.SetAreaEnabled.
Note: Custom Profiler modules that use built-in counters enable the built-in counterâs area, even if the module it belongs is disabled. To prevent the Profiler from collecting these statistics and creating collection overhead, make sure that both the built-in Profiler module and your custom Profiler module are disabled.
Script update markersUnless youâre using the job system, most of your scripting code is nested underneath the following markers. For information on job system samples, refer to the Multi threading markers section of this page.
For further details on Unityâs Update Loop, refer to the documentation on Order of execution of event functions. You can insert your own callbacks into the Player Loop using PlayerLoop.SetPlayerLoop. If you insert callbacks directly into the main loop, your script update samples appear on their own. If you insert callbacks as a subsystem, the samples appear under the respective main PlayerLoopSystem marker.
These markers contain the samples where the CPU spends time processing data for the GPU, or where it might be waiting for the GPU to finish. If the GPU Profiler module isnât available, or it adds too much overhead, the toolbarA row of buttons and basic controls at the top of the Unity Editor that allows you to interact with the Editor in various ways (e.g. scaling, translation). More info
See in Glossary in the Profiler module details pane doesnât display this information. The samples under these markers can give you a good idea of whether your application is CPU-bound or GPU-bound.
Application.targetFrameRate specifies.
If the sample is a subsample of Gfx.WaitForPresentOnGfxThread, it represents the amount of time that your application spent waiting for the GPU. For example, this could be time that the GPU spent waiting for the next VSync, if that is configured in QualitySettings.vSyncCount, or if vSync is enforced on your target platform. However, samples with this marker are also emitted if the GPU hasnât finished computing the frame.
To determine what is causing samples with this marker to use a lot of time, switch to the Timeline view in the CPU Profiler module. In this view, you can check what happened on the render thread and how much time passed between this sample ending in the current frame and the same sample ending in surrounding frames.
If the duration is larger than your applicationâs frame time should be (based on the targeted frame rate or vSync) your frames are taking too long to render or compute. If thatâs the case, investigate the render thread and see how much time it spent on Gfx.PresentFrame over other work it did to prepare and issue commands to the GPU. If the render thread spent a large amount of time in Gfx.PresentFrame, your rendering work is GPU-bound. If the render threadâs time was spent preparing commands, your application is CPU-bound.
To find out what to focus on, if your application is GPU bound, profile the GPU work with the Unity Profiler or a platform profiler. For more information, see the User manual documentation on how to optimize graphics performance.
Note: The Editor doesnât VSync on the GPU and instead uses WaitForTargetFPS to simulate the delay for VSync. Some platforms, in particular Android and iOS, enforce VSync or have a default frame rate cap of 30 or 60.
Gfx.PresentFrame Represents the time your application spent waiting for the GPU to render and present the frame, which includes waiting for VSync.Samples with the WaitForTargetFPS marker on the main thread show how much time is spent waiting for VSync.
Gfx.ProcessCommands Contains all processing of the rendering commands on the render thread. Your application might have spent some of this processing time waiting for VSyncVertical synchronization (VSync) is a display setting that caps a gameâs frame rate to match the refresh rate of a monitor, to prevent image tearing.<GraphicsAPIName>.WaitForLastPresent for example:
Time.frameCount - QualitySettings.maxQueuedFrames + 1). This means that if QualitySettings.maxQueuedFrames is greater than one, this time is spent waiting for the GPU to flip a frame that your application requested to render in a previous main thread frame.
For more details on this sample and an overview of Unityâs Frame Pipeline, see Unityâs blog post on fixing Delta Time.
Gfx.WaitForPresentOnGfxThread Indicates that the main thread was ready to start rendering the next frame, but the render thread didnât finish waiting for the GPU to present the frame. This might indicate that your application is GPU-bound. To check what the render thread is simultaneously spending time on, check the CPU Profiler moduleâs Timeline view.If the render thread spends time in Camera.Render, your application is CPU-bound and might be spending too much time sending draw calls or textures to the GPU.
If the render thread spends time in Gfx.PresentFrame, your application is GPU-bound, or it might be waiting for VSync on the GPU. A WaitForTargetFPS sub-sample of Gfx.WaitForPresentOnGfxThread represents the portion of the Present phase that your application spent waiting for VSync. The Present phase is the portion of time between Unity instructing the graphics API to swap the buffers, to the time that this operation completed.
The samples highlight Mono or IL2CPPA Unity-developed scripting back-end which you can use as an alternative to Mono when building projects for some platforms. More info
See in Glossary scripting backendA framework that powers scripting in Unity. Unity supports three different scripting backends depending on target platform: Mono, .NET and IL2CPP. Universal Windows Platform, however, supports only two: .NET and IL2CPP. More info
See in Glossary activities and are useful for troubleshooting issues with garbage collection and allocation.
This interruption might cause delays in the execution of your application that last anywhere from less than one millisecond to hundreds of milliseconds. This depends on how much memory the garbage collector needs to process and the platform your application is running on. For more information, see the documentation on Understanding automatic memory management.
Mono.JITThese markers contain samples that donât measure the CPU cycles consumed, but instead highlight information that relates to thread synchronization and the job system. When you see these samples, use the CPU Profiler moduleâs Timeline view to check whatâs happening on other threads at the same time.
Marker Description Idle Contains samples that indicate the length of time that a Worker Thread is inactive for. A worker thread is inactive any time that the job system doesnât use it, and it goes into wait mode, where it waits on the semaphore.Small gaps between Idle samples usually happen when the Job System wakes them up, for example, to schedule new jobs. Longer gaps might indicate that a native job that hasnât been instrumented is running on the thread.
JobHandle.Complete Contains samples that indicate when a sync point on a job happened. Sync points might have a performance impact on your application and might interfere with the execution of multi-threaded job code. To make it easier to find where exactly the sync point happened, enable Call Stack recording for this sample. In the CPU Profiler moduleâs Timeline view you can enable Flow Events to identify which jobs finished at this point. Semaphore.WaitForSignal Contains a sample that depicts a synchronization point on a thread. To find the thread itâs waiting for, check the Timeline view for samples that ended shortly before this one. WaitForJobGroupID A Sync Fence on a JobHandle was triggered. This might lead to work stealing, which happens when a worker finishes its work and then looks at other workersâ jobs to complete. These display as job samples executed under this marker. Jobs that were stolen arenât necessarily the jobs that were being waited for. Physics markersThe following table outlines some high-level physics Profiler markers. FixedUpdate calls all these measurements.
Physics.Interpolation method. This method manages the interpolation of positions and rotations for all the physics objects in your application. Physics.Processing Contains samples that spent time waiting on the main thread until the physics simulation completed across all threads. If your application spends a lot of time in Physics.Processing but only has a few physics related GameObjectsThe fundamental object in Unity scenes, which can represent characters, props, scenery, cameras, waypoints, and more. A GameObjectâs functionality is defined by the Components attached to it. More infoPhysics.ProcessingCloth method. This method processes all cloth physics jobs. Expand this sample to display the low-level detail of the work done internally in the physics system. Physics.ProcessReports Contains samples that correspond to time spent forwarding physics data to scripts via callbacks such as OnTriggerEnter. Note: These samples donât compute the data required because they have already been prepared during FetchResults.
There are four distinct stages:
Physics.Contacts. This processes OnCollisionEnter, OnCollisionExit, and OnCollisionStay events.Physics.JointBreaks. This processes updates and messages related to broken joints.Physics.TriggerEnterExits. This processes OnTriggerEnter and OnTriggerExit events.Physics.TriggerStays. This processes OnTriggerStay events.Physics.Simulate method. This method instructs the physics system to run its simulation, which updates the state of the current physics. Physics.UpdateBodies Contains samples that update all the physics bodiesâ positions and rotations. For each GameObject that has a RigidbodyA component that allows a GameObject to be affected by simulated gravity and other forces. More infoPhysics.UpdateCloth method. This method processes updates that relate to cloth and their Skinned Meshes.
For more information about script lifecycles and general samples within a script lifecycle, refer to Order of execution for event functions.
Animation markersThe following tables contain markers from the Animation system. For general information on Animation system performance, refer to the Mecanim Performance and and Optimization page.
PreLateUpdate.DirectorUpdateAnimationBegin stageIn this stage, every Animator thatâs active and enabled is processed. Active Animators are processed regardless of Culling Mode and visibility.
Markers that start with Director. can also cover PlayablesAn API that provides a way to create tools, effects or other gameplay mechanisms by organizing and evaluating data sources in a tree-like structure known as the PlayableGraph. More info
See in Glossary and Timeline.
Director.PrepareFrameJob jobs. These jobs evaluate the state machinesThe set of states in an Animator Controller that a character or animated GameObject can be in, along with a set of transitions between those states and a variable to remember the current state. The states available will depend on the type of gameplay, but typical states include things like idling, walking, running and jumping. More infoEvaluation of state machines with StateMachineBehaviours that implement OnStateMachineEnter or OnStateMachineExit listeners will be constrained to the main thread.
Animator.ProcessGraph jobs. Animators.ProcessGraph (job) Evaluate all properties across all connected AnimationClips.
Calculate the root motion displacements by blending the root motion properties from all clips together.
Collect new animation events for the current deltaTime.
When evaluating AnimationClipsâ properties, the curve segments are cached locally between frames to avoid reading from the AnimationClipsâ memory more than necessary.
Animators.FireAnimationEventsAndBehaviours Fire all animation eventsAllows you to add data to an imported clip which determines when certain actions should occur in time with the animation. For example, for an animated character you might want to add events to walk and run cycles to indicate when the footstep sounds should play. More infoStateMachineBehaviours and MonoBehaviours, except OnStateMachineEnter or OnStateMachineExit listeners which have already been fired in Director.PrepareFrameJob. Animators.ApplyOnAnimatorMove Apply root motionMotion of characterâs root node, whether itâs controlled by the animation itself or externally. More infoOnAnimatorMove message on MonoBehaviours. PreLateUpdate.DirectorUpdateAnimationEnd
In this stage, only Animators with the Culling Mode Always Update and visible Animators with the Culling Mode UpdateTransform or Cull Completely get processed. Animators with Cull Completely that were moved out of frame by the Root Motion donât participate in this phase. Neither do Animators that were disabled by user code triggered by StateMachineBehaviours and AnimationEvents
Animators.SortWriteJob groups Animators.WriteTransforms jobs by their Transform.root.
For the best performance, avoid having multiple Animators in the same transform hierarchy to increase the granularity at which jobs can be scheduled and parallelized.
Animators.ProcessAnimationsJob Build, schedule, and await the results ofAnimators.ProcessAnimations jobs. Animator.ProcessAnimations (job) Blend all properties on current active AnimationClips for a single Animator, except for root motion. Apply them to the internal avatar representation.
The length of this marker scales with animation and blending complexity.
OnAnimatorIK Sets up animation IK. This is called once for each Animator ControllerControls animation through Animation Layers with Animation State Machines and Animation Blend Trees, controlled by Animation Parameters. The same Animator Controller can be referenced by multiple models with Animator components. More infoAnimator.WriteTransform jobs. These jobs write transform poses from Animation avatarsAn interface for retargeting animation from one rig to another. More infoThe CPU Profiler detects some common performance issues and warns you about them. These appear in the Warning column of the CPU Profiler moduleâs Hierarchy view in the module details pane.
The Profiler detects some specific calls to avoid in performance-critical contexts. It displays the warnings with the reasons the operations are affecting performance as follows:
Warning Description Animation.DestroyAnimationClipThis is a resource-intensive operation, so you should avoid calling these methods at runtime as much as possible.
AssetBundle.asset/allAssets Indicates that Unity called the AssetBundleRequest.assets/allAssets API while the AssetBundle loading was not complete (AssetBundleRequest.isDone is false). This causes a stall on the main thread and waits for the loading operation to complete. AsyncUploadManager.AsyncBufferResizedYou can avoid this warning if you can spare the memory to allocate a larger size up front.
You can use Async Upload Buffer Size setting in Quality Settings to set the default size.
The AsyncUploadManager.AsyncBufferResized marker indicates the newly allocated size which you can use as a guide for the default buffer size.
Profiler command line arguments
Profiler counters reference
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4