Fix: Unity Profiler Showing "Editor Loop" Taking All Time

Here is how to fix Unity Profiler showing “Editor Loop” taking all the time. You open the Profiler to find a performance regression, click through a few frames, and the CPU Usage module shows Editor Loop consuming 18 ms of a 22 ms frame. PlayerLoop — where your actual game code lives — is a sliver. You try to drill into Editor Loop and it is opaque: no callstack, no breakdown, just a solid bar labeled “Editor Loop.” The number looks alarming but it is almost never what you think it is.

The Symptom

In the Profiler’s CPU Usage module, a large portion of each frame is attributed to Editor Loop. Your game’s PlayerLoop — Update, FixedUpdate, rendering, physics — totals a reasonable few milliseconds, but the overall frame time is much higher. The stats bar may show 30–45 FPS in the editor while the Profiler claims your game logic only takes 4 ms. The gap is all labeled Editor Loop, and clicking it reveals nothing useful.

The confusing part: if you disable the Profiler and just look at the Stats overlay, your game still feels slow. The Editor Loop cost is real, it is just not your game’s fault — which matters because every optimization you try in game code will show no effect in the Profiler.

What Causes This

Editor Loop is everything outside PlayerLoop. The Unity editor runs on the same thread as your game during play mode. Scene View rendering, Inspector repaints, asset import jobs, the Hierarchy window updating, EditorWindow.OnGUI for every open window, and editor-only scripts with [ExecuteAlways] all count as Editor Loop. The Profiler categorizes them together because they share the same root (EditorApplication.Tick).

Scene View is usually the biggest culprit. A Scene View open on a large scene re-renders every frame, independently of the Game View. If your scene has expensive shaders, lots of gizmos, or editor-only OnDrawGizmos implementations, the Scene View pays all of that cost every frame on top of your Game View. Closing the Scene View can halve your apparent frame time.

Inspector on a noisy object. If the Inspector is pinned to an object with many components, custom editors, or a PropertyDrawer that does expensive work in OnGUI, the Inspector repaints every frame and runs that work every frame. Custom inspectors that query the scene or re-serialize large arrays on every GUI frame are particularly bad.

Asset import and script compilation. If Unity is importing an asset or compiling scripts in the background while you are in play mode, that time gets attributed to Editor Loop. You will see sporadic spikes rather than a sustained high baseline.

[ExecuteAlways] or [ExecuteInEditMode] scripts. These run in editor tick as well as play mode. If one has a heavy Update method, it contributes to Editor Loop overhead.

The Fix

Step 1: Enable Deep Profile. In the Profiler window toolbar, click the “Deep Profile” button. This instruments every managed method call, including the contents of Editor Loop, so you can see what is inside. Deep Profile has a huge overhead (often 3–5x slower), so only use it to identify what is expensive, then turn it off.

With Deep Profile on, you will see Editor Loop expanded into entries like SceneView.Repaint, GameView.Repaint, InspectorWindow.OnGUI, HierarchyWindow.DoItemGUI, and various AssetDatabase calls. Click through to find which one dominates.

Step 2: Close non-essential editor windows. Before a profiling session, close the Scene View, any second Game View, Inspector, Hierarchy, and Project windows you do not actively need. Dock everything except the Profiler and a single Game View. Compare frame times before and after. If Editor Loop drops significantly, editor UI was the problem.

Step 3: Profile a player build. This is the only reliable way to measure real game performance. Build a Development Build with the “Autoconnect Profiler” and “Deep Profiling Support” options enabled. Run the build, and the Profiler connects automatically. In a player build, there is no Editor Loop — only PlayerLoop.

// Build settings for accurate profiling
BuildOptions options = BuildOptions.Development
                     | BuildOptions.ConnectWithProfiler
                     | BuildOptions.EnableDeepProfilingSupport;

BuildPipeline.BuildPlayer(scenes, path, target, options);

Step 4: Disable expensive gizmos in Scene View. Open the Gizmos dropdown in the Scene View and uncheck any script with expensive OnDrawGizmos. Custom gizmos that draw many lines, spheres, or meshes every frame add up quickly. You can also globally toggle gizmos off with the Gizmos button in the Scene View toolbar for profiling.

Custom Editor Cost

If Deep Profile shows InspectorWindow.OnGUI taking most of Editor Loop, your custom inspectors are expensive. Common offenders: calling FindObjectsOfType in OnInspectorGUI, iterating large serialized arrays every frame, or running code in the editor that should only run on property change.

Wrap expensive work in EventType.Repaint checks so it only runs on repaint frames, not on every layout pass. Cache results across frames where possible. Move one-time work to OnEnable or OnValidate rather than OnInspectorGUI.

When Editor Loop Is Legitimate

Some Editor Loop cost is normal. Unity’s editor has to update the Hierarchy, tick its own systems, and repaint the Game View. Expect 2–5 ms of Editor Loop even in a minimal project. It is only a problem when it dwarfs PlayerLoop or when optimizing your game code shows no improvement because Editor Loop dominates.

“The Profiler in the editor is great for finding hotspots in your scripts. For measuring total frame time, build and run. Do not ship based on numbers from the editor.”

Related Issues

If the Profiler is specifically slow to scrub through frames, see Unity Profiler Window Slow or Unresponsive. For profiling deeply in builds, Unreal Insights Performance Profiling Guide covers similar concepts for Unreal, and Error Logging Best Practices covers how to correlate profiler data with bug reports.

Always profile a player build for shipping numbers. The editor lies.