Massive CPU Usage by WaitForTargetFPS in the Profiler

Question

So I was checking the Standard Assets Example Projects of Unity, and they all have high FPS numbers in the Profiler.

I started a little project myself, just a simple sprite with movement via rigidbody and a plane as a floor, and suddenly this:

I searched for what exactly does WaitForTargetFPS represents, but apparently there is not a general consensus about what can cause such high CPU usage. So why exactly such a little and simple project have this performance (in contrast with the more complex Unity Example Projects)?

Answer 1

the reason those things happen is because Unity's is limiting your FPS and that process tells you by how much its limiting it, since regular machines can reach as high as 60 FPS anyway theres no need to use 600 FPS CPU and waste all that power for nothing.

the best you can do to solve that annoyance on the profiler is to just deselect Vsync from the profiler menu.

you can always disable Vsync from Menu: Edit > Project Settings > Quality, scroll all the way down and select Disable for "V Sync Count", bare in mind the first option is better for performance checks.

Answer 2

I saw some misunderstandings about this cropping up in recent questions, so I thought it would help to cite the documentation here too: (emphasis added)

WaitForTargetFPS

Indicates how much time your application spent waiting for the targeted FPS that 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.

So: seeing high amounts of time spent in WaitForTargetFPS is not necessarily a problem.

If your overall framerate is still on-target, then this just means you have extra frame time headroom that the editor is burning, rather than simulating and drawing frames far faster than your display could ever keep up. It's a good sign that your CPU and GPU work finished so fast that you have this extra time to kill. In a build, this is time when your thread would usually be sleeping, saving power and heat.

High usage by the WaitForTargetFPS marker is only a problem if your overall framerate is dropping lower than your goal. In that case, follow the advice in the docs quoted above to identify which part of your code is taking up most of this marker time to figure out whether it's CPU or GPU work that's running behind.

In the screenshot here, the total frame time is still averaging about 10 ms, or 100 FPS, so this example is soundly in the "not a problem" category. That's why the other answer recommends just toggling off visualization of this spare time if seeing it in the graph is distracting.