- Home /
WaitForSeconds vs yield every frame
Currently I use
float done = Time.time + delay;
while(Time.time < done) yield return 0;
as a replacement for
yield return new WaitForSeconds(delay);
because it works with different time scales.
Is it more expensive? Is there more overhead? If so, how much, relatively speaking? Is it just the same, just without constructing an extra class?
Please do not respond if you're just guessing.
Why do you even care? Neither code is good if you plan to have any sort of pausing mechanism in your game. Use a function elsewhere that updates if you're not in paused mode, using yield return 0, and don't rely on Time.time, but ins$$anonymous$$d, increment another timer variable, and end the loop when IT is greater than "done".
Where's the difference between using another variable ins$$anonymous$$d of Time.time if I can just affect Time.time easily with timeScale? If I set timeScale to zero, my game pauses perfectly, including sounds, particles, animations and all my waiting enumerators. So why would I want to replace that with something more custom where I have to stop animations and what-not by hand? $$anonymous$$aybe you have a much better approach, but for me this works absolutely perfect. And if I want something not to be affected by Time.time I can always use Time.realtimeSinceStartup.
Answer by Max Kaufmann · May 07, 2010 at 07:34 PM
If you look into .Net's assemblies you'll see that each "yield"ing function returns an instance of a generated class which includes your local variables as instance members and injects your method body into it's MoveNext() method and fills it with IL-level gotos (this is what the IEnumerator handle is actually pointing at).
So the overhead is negligible in this case - you're not creating a thread of some other expensive system resource, just another vanilla method callback.
Yea, but doesn't the Yield WaitForSeconds(x) tell some internal co-routine dispatcher to not call you for x seconds. Where as yielding every frame will cause your coroutine to get dispatched every frame, this is essentially a busy loop and uses more CPU.
Answer by Waz · May 27, 2010 at 11:15 PM
It depends entirely on "delay". If "delay" is 10, then the first code will be creating 500 yields (at 50Hz) during that 10 seconds (instead of one for the latter code). If delay is 0.02, they'll be equivalent. As to whether it's negligible with large "delay", that'll depend on how many of these coroutines you have running (certainly for 20 or so it's negligible, since it's only 20 per frame). But your question is a good answer to "Does WaitForSeconds work for different timescales?"... which is what I was looking for - thanks!
Are you certain that WaitForSeconds is only yielding once? I'd not be surprised if internally it works exactly the same - but that's why I'm asking. After seeing how slow Unity's $$anonymous$$ath functions are, for example, I've become a bit suspicious with Unity methods that I can't look into.
Answer by Ashkan_gc · Apr 09, 2010 at 03:27 PM
when you use WaitForSecond unity checks the timer of your coroutine and the end of each frame and see it's not the time to run it but when you use your own code to check it unity should execute a few instruction in each frame for your script. there is not much difference if you don't use it in many objects on iphone. the class is so light weight so creation of WaitForSecond don't take much time. it might be slower on 0.05 second. you can test things like this with attaching 2 different scripts to more than 5000 GameObjects and take a look at CPU usage and FPS.
That testing is actually a good idea. Wish I had time for that right now.
Your answer
Follow this Question
Related Questions
WaitForSeconds while having an Update/CoUpdate in C# 1 Answer
Destroy then Clone Help please? 2 Answers
Yield causing 2D animation to pause 1 Answer
(c#) Problems with yield 1 Answer
Mysteries of yield 1 Answer