there's better ways to code this that should work better but it's not trivial as far as I can see).
And I'm using the WaitForSecondsRealtime that came with Unity (not sure when they introduced it, 5.4 or so I guess -) ), not my own implementation like (btw, the reason this doesn't work is that you need the constructor in your code if you add a method that does the same thing as the constructor and call it before the yield, it will work. Turns out that while this works just fine with WaitForSeconds, doing it with WaitForSecondsRealtime will result in no waiting at all. I just found this because I broke quite a bit of stuff in my game simply keeping WaitForSecondsRealtime in variables instead of instantiating new ones every time. The standard new WaitForSeconds() method it is not so bad, causing about 0.01175KB of garbage per YieldInstruction.Ĭaching YieldInstructions as exposed at the begining of the thread can help reduce the GC load. This will create a new Coroutine object and all the overhead Unity needs to do to handle a new Coroutine.Īs can be seen at this profiler window, each frame the 1200 CoroutineUser objects need to wait will cause allocs of 57.4KB, Iterator.ctor() can be seen within the stack hierarchy.ĭue to the size of the allocs this method will cause GC calls to be more often.
Starting a new "nested" Coroutine within a Coroutine (Coroutineception!) as powerful as it can be is a double edged sword and must be used carefully. ctor() can be seen within the stack hierarchy. In the profiler window can be seen the 1200 calls to () and the 0KB allocs.Īlso no. Having a strong reference to those objects will keep them away from the GC and can be purge at will ensuring GC calls to be made in safe zones, like before/after Application.LoadLevelAsync for example. Note: I do recommend to disable VSync to be able to spot more easily the cpu spikes at the profiler.Ĭreating new Yielders will cause allocs on the frame the instruction was created, and it will be disposed right after the yield statement has finished thus generating GC calls every once in a while.Īs can be seen in the profiler window, the 1200 calls to () will cause allocs of 14.1KB and 1200 WaitForSeconds.ctor() can be seen within the stack hierarchy.Ĭaching the YieldInstructions within a static dictionary will cause allocs the first frame the Yielder is needed and subsequently will reuse those objects. When run, the screen will be "mostly" covered by the same sprite, starting all with white tint and every "x" seconds a row will switch colors.įor best results I do encourage making a "deep profile" With the use of preprocessor symbols we can change the test to be run, thus only changing the lines corresponding with the "Wait" part of the process. To create a few dynamism within the test there are three prefabsĮach Coroutine User has a sprite component attached and will change its color every "Delay" seconds. The scene is simple, it has a camera and 12 spawners, this will instantiate prefabs that use Coroutines to increase the load and catch alloc and cpu spikes while profiling.Įach Spawner has a CoroutineUser prefab and will create 100 of them. This was tested with Unity 4.3 (yes kind of old but. I took the time to make some tests, profile them and record the results. Well I wouldn't concern so much about the dictionary, if it is handled correctly It can even store a few hundred items and really don't cause much trouble for fetching values.
#Awaken my love vinyl reuse code update#
I have implemented it in my current project using coroutines for almost everything (AI loops, bullets, explosions, slow-mo effects, UI updates and such), the shared Yielders have not caused any bug or issue and have reduced the GC Alloc each shared/cached YieldInstruction will save just a few bytes (not a big deal), in the other hand creating them once they are needed will cause problems as Coroutines can be used heavily by multiple objects on multiple consequent frames and then released (once the coroutine has continued execution) the continuous allocation of YieldInstructions will trigger the Garbage Collector to clean the HEAP memory, THIS is the real issue here, GC is expensive and most of the time the only reason to have FPS drops or game update glitches.Ĭlick to expand.Sorry for the late response, Hence they are not bound to the gameobject itself nor time of creation it is safe to share them between objects. Therefore creating a new WaitForSeconds(1.0f) object at t=0 and then creating another new WaitForSeconds(1.0f) at t=1 causes the same effect as sharing the object in a cached value. each coroutine must be handling internally the wait logic especially the elapsedTime (WaitForSeconds). Click to expand.As I could gather the YieldInstructions (WaitForSeconds, WaitForEndOfFrame and WaitForFixedUpdate) are handled by the coroutines just as a delimiter or conditional break.
0 kommentar(er)
