Time.time vs Time.deltaTime efficiency.

Questions & Answers
1

If I want to call a function let’s say every 5 seconds, I have 2 options of doing it.

1st option - Time.deltaTime:

private float timer = 0;

void Update () {
    timer += Time.deltaTime;
    if (timer >= 5) {
        timer = 0;
        functionToCall();
    }
}

2nd option - Time.time:

private float timeToCallNext = 0;

void Update () {
    if (Time.time >= timeToCallNext) {
        timeToCallNext = Time.time + 5;
        functionToCall();
    }
}

Now, I’ve always been using the first approach, but with a lot of timers it usually became quite difficult to manage. With the second approach however, I don’t like the fact that the Time.time will always keep increasing.

Which method is more CPU intensive? I believe that the first one would use more RAM, as more variables are created? Would the second approach ever fail?

(These micro-optimisations are important to me.)

3

Both Time.time and Time.deltaTime is lookups of static variables. Since the variable is the same throughout the entire frame, they seem to be cached, so there’s no difference between the two.

Not that this kind of “optimisation” will ever be noticeable unless it’s running in a loop somewhere.

2

If all you’re trying to do is call a function after a certain amount of time, you can just invoke it.

Invoke(string methodName, float time);

Much easier to read as it’s only a single line and very easy to keep track of.

4

So for a more full explanation, They are both about the same in the end, but the bigger issue is code readability/maintainability. As the OP pointed out it is fine with one, but what about when you need 10, or 20 in a method? Then doing the cleanest is best, which would have to be using Time.time. There is one better, which would be close to what srylain suggested, but instead of using invoke start a quarantine, as then you can just use wait for seconds, or yield return null; if you want to iterate one frame at a time to update every frame. Using IEnumerators has some penalty, so should only be used if there are more then one timer, and one should never call yield return new waitForSeconds(); in a loop as that makes an object every time, and should be taken out of the loop aslong as it won’t change. Like wise use yield return null; instead of 0, as 0 is wrapped as a real response, and null is ignored. Also remember any Behavior with Update() on it has a small penalty so if your timer is barely ever used the small impact of calling an IEnumerator is less then having tons of Update() calls checking to see if they should run.
The next issue is How long will Time.time be reliable which I will point to the answer from this thread, but TLDR: you have 9h of straight runtime before stuff goes wronge with Time.time, but Time.deltaTime is safe. My suggestion for keeping the clean look of the second, but precition of the first would be IEnumorator again, or make a timer struct that can be checked/updated with one call, Something like.

if (m_myTimer.CheckTime())
{
    OnFinished();
    m_myTimer.Reset();
}