Profiler - WaitingForJob really high

Hello everyone !
I am trying to optimize my game, and I have noticed in the profiler than the WaitingForJob took too much FPS.

It's Time ms is between 5ms and 40ms (!) . Usually, it raise with time, while my game is getting slower and slower...

I was first thinking that "waiting for job" meant there was nothing happening, but now I am not so sure...
Is someone able to explain me what it is exactely ? Thanks
I attached a screenshot of it.

 

WaitingForJob basically means some other thread has higher priority so the main thread is supposed to wait
In the profiler you can bring up the Timeline for a more indepth look if its any of Unity's worker threads thats causing the holdup

I'd look into cleaning up that enemyComportement.SetupCoroutine.

when the GC runs the thread has to wait for it to complete before it can continue.
you're throwing away over 6kb of data per frame in it, which is excessive. it should be possible for you to cache your data so that you can reuse it in later frames

 

Thanks Joshua for your answer.
Actually, I managed to get rid of that WaitingForJob non sense : As the big noob I am, I had child everything on my scene (including a lot of 3D models) under a Canvas with a Graphic Raycaster active. Which was definitely not a good practice
So now that I have put everything under a classic empty object, I bearly excess the 10 ms line, which make my game a lot more fluid

However, I am curious about what you said about my script enemyComportement, and maybe you can help me to optimize things by answering this question :

EnemyComportement is a script I attached to every monsters I instanciate in my game, which control their behaviour (how they move, their direction, rotation, their life, their attacks, their loots...). I have about 50 monsters in the scene. The question is :
Is it better to have a script for each object instantiated which dies when the object dies, or is it better to have juste one script which stays on the scene, and which will take care of every instances when they are create ?

Other question : I have get rid of most of my Update() and FixedUpdate() functions to replace them with coroutines, which was looking more optimised. Was that a good idea ?

About the 6KB data (which I am not sure to understand what it is), it's now 488B now that I correct the canvas issue.
I have attached a new screenshot of my current profiler, if you want to have a look.

Thank you
And sorry about my strange english, it is not my native language as you could have noticed

 

The answer to that is it depends. having each object have their own script makes the code far simpler to manage each instance's state.

If nearly every instance has the exact same data and there's a lot of them (for example a particle system where all particles had the same lifetime, color over life, and range of movement) then its more memory efficient to use whats called the flywheel pattern where you have one manager object with a single set of data that all the instances share, and then each instance only stores data that'd be unique to itself (for example, a particles current position, age, and likely a seed for calculating random ranges). also each instance is is not a " class instance" but an array of values. otherwise you would have extra overhead for each class instance, flywheel is specifically designed to reduce memory costs so its great for things like particles and trees, where the specific individual is not that important so much as the display of the entire group

but this is not the problem you're having. your problem stemmed from your canvas trying to clear the meshs in the hierarchy every frame for rendering. now looking at your profiler, there are no issues to worry about to optimize. I wouldn't waste my time trying to optimize things that aren't a problem

for the most part, its not a matter of if its a good idea or bad idea, but more a matter of preference. If written correctly the performance difference between Update/FixedUpdate and coroutines will be negligible. Coroutines have the benefit of being more coherent for behaviour spanning multiple frames, while Update/FixedUpdate will run automatically even after the script is disabled and reenabled (coroutines will be stopped and lose their progress OnDisable, and you have to manually restart them OnEnable, and overall require more work to set up)

 

Thank you for your long answer Joshua, I will try to learn more about flywheel patterns.
Two hours ago, I was thinking I had finish my project, but I have "an Access Violation (0xc0000005)" big crash which occure randomly when I play (windows export), after 10, 20 or 30 mn, without any pattern. So that became the major first primary bloody priority now =S
Thanks again ! (and of course if you can help me with this, I am all listening error.log attached)