Time Functions Returning Incorrect Time Values

I'm seeing Time.deltaTime and Time.unscaledDeltaTime return values that do not match what I would expect given the Profiler and stats views in terms of FPS/frame time.

To repro this, I made an empty project with a single C# script that sets a public variable to what should be the framerate for the given frame. The inspector updates every frame, however the FPS is always roughly 1/4 to 1/3 the expected time.

Am I missing something? FPS scripts that I could find do the same thing, so I don't think I'm purposefully glossing over anything here.

Code (CSharp):

1. public class FPS : MonoBehaviour
2. {
3.     public float fps = 0.0f;
4.  
5.     void Update()
6.     {
7.         fps = 1.0f / Time.deltaTime;
8.     }
9. }

 

This is a timeworn subject and it boils down to this: the profiler is showing you the frames per second that would be achieved if every frame of your game ran consecutively back-to-back without any kind of waiting imposed by the external runtime environment that your game is running within, such as (but NOT limited to) vsync, etc. For example, if the profiler counts all of your game's work for a single frame as taking 0.01 seconds, then it will show you an FPS of 100.

However, the actual real time between frames is almost always limited by environmental factors, such as how often the hosting runtime can refresh the screen - even WITHOUT waiting for vsync. This is true even with vsync turned off and targetFrameRate set to 0 or high values. Therefore your Time.deltaTime is telling the truth - the actual wall clock time between this frame and the last one can be, and in simplified testing projects, often actually is - longer than the time that all of the last frame's work required.

When optimizing, you should let the profiler's FPS number guide you. If the computer you're testing on isn't capable of actually presenting frames at that higher rate that you're achieving, then this is OK - you are now saving precious power by getting your frame's work done in a shorter time than necessary, allowing the CPU and GPU to become idle or work on other processes until the next frame can be worked on.