I have set 2 profilers (using ‘Stopwatch’), both start in the very first ‘FixedUpdate()’ called (or the very first ‘Update()’ if there was no ‘FixedUpdate()’ call this frame), one end in a ‘WaitForEndOfFrame’ Coroutine and the other ends just before starting again.
Here are the results:
‘Complete frame’ called 1647 times. Total time: 18714.2713ms. Time per frame: 11.363ms.
‘Full frame’ called 1647 times. Total time: 15061.5675ms. Time per frame: 9.145ms.
V-Sync is off.
I did that test on a scene where nothing moves, so that there was something (quite complex) rendered, but no variations over time.
It means that there’s no GameObject creations, in fact nothing happen, and I have only one coroutine, the one used for the profiler.
Note that ‘Update()’ has been called 1647 times and ‘FixedUpdate()’ has been called 1836 times (I’ve set the timestep so that I’m sure that each frame there will be at least one ‘FixedUpdate()’ call in order to catch the very start of the frame).
It means that I catch the very start of a frame, and the very end of a frame (according to the ‘Order of Execution for Event Functions’ page of Unity).
It means that Unity is spending about 20% of the time between 'WaitForEndOfFrame’and ‘FixedUpdate()’.
Does anyone knows what is happening there?
We obviously can put some threads to work during that time, but without the answer to those questions we may hinder the work of Unity itself:
Is it using all cores or is it only used by the main thread?
Is the GPU used during that time?
Im not sure if this answers you main question, but
The unity engine does only use one thread, and in fact most of it cannot be accessed from any other thread
The rendering process happens after Update() and LateUpdate(), which you can see in this graph: https://docs.unity3d.com/Manual/ExecutionOrder.html , however i’m not entirely sure when compute shaders run, which is also a way to utilize the GPU. But i dont think you meant that.
You say “Unity is spending about 20% of the time between 'WaitForEndOfFrame’and ‘FixedUpdate()’”, however FixedUpdate() is not called every cycle. Unity does its best to call FixedUpdate() in fixed time intervals, independant of what the framerate is. WaitForEndOfFrame however, happens once a frame. Technically you could have douzens of those between a single FixedUpdate() call.
You should maybe check out the Profiler Window. Particularly the Timeline view will give you a more detailed account of what’s happening when in the frame, on what thread and how work transitions between frames.
Thanks, I had never tried the timeline option before, it’s quite nice!
Its UI could be better, it’s a bit hard to scroll horizontally when you are at maximum zoom, but overall it’s quite useful.
When I looked into the timeline, I saw that after the ‘WaitForEndOfFrame’ call, Unity is spending more than 1ms doing nothing, and after that it does some profiler thingies.
Before the first ‘FixedUpdate()’, there are some canvas-related thingies (and a few small things I haven’t really identified), for about 0.1ms (I have no UI, I guess that with a complex UI it could take more than that).
I feel a bit silly, my previous tests were only done within Unity, I forgot the golden rule: always profile the release.
I have tried in release, and the results are quite different, there’s only 0.15ms difference, which is explained by the canvas thingies done before we get the hand.
So that answer my question:
There’s nearly nothing between the end of a frame and the start of the next frame, except for some canvas thingies.
And profiling in Unity gives really false results (which isn’t a criticism, it’s perfectly normal to have false profiling results in a debug environment).