The overhead at the end is not from job side, you are not disposing the rotation native array. And also you should not allocate and dispose the arrays each time since you are using the Persistent allocator, so either keep their reference by creating them at awake and disposing them in on destroy or simply allocate them and dispose them in update with a temporary allocator.

Really cool overview. Really appreciated the look at 15,000 individual jobs because I think the overhead would catch many out!

I know you since 1k subs, I am glad u didn't gave up and are that far on youtube, hope you are making a good living now, at least good enough to survive

Side note on performance improvement, (the rotation not being disposed and persistant have already been addressed). You should swap using Distance for DistanceSquared (ie : comparing the squared distance instead of the normal distance). The normal distance, include a squareRoot in its calculus which is def more costly that squaring the constant you are comparing it to.

A good video. I suspect some people may benefit from clarity that, essentially, every time you say 'thread' you could say 'core'. That's what you're allowing here; to spread more work across more CPU cores. I also like that you touched on their being no free lunch; it comes with its own overhead as everything does.

Okay.. Im going to give this another shot. I need to start showing viewers how to make cool games and get more viewers. tough. Great video man

Excellent tutorial!

Just to add my take on "why 2 libraries for Jobs exist" and also why we keep seeing libraries (namespaces) with the same name. I am not sure if this is exactly the case but the JOBS library is an isolated solution. It might not necesserally been written to work solely for the UnityEngine. It is a solution on multithreading in a specific scenario. So you have the solution "Unity/Jobs" (using slashs so youtube does not mistake it with a link). It contains everything to make Jobs work. And then you need an implematation that actually takes advantage of that system and applies its usage in the way it needs to its own solution. That's why you have the "UnityEngine/Jobs". It is basically the UnityEngine having an implementation on how to use the Jobs library, wich happens to be made by Unity (the company).

Im a godot developer but love your videos. Feel like i still got a little out of it. Helps that I use c# in my day job and use threading frequently. Thanks for the vid!

Oh boi that was a nice explanation.

Cool video. I want to point out that although the ~x2 boost in your example does not look that impressive, actually, excluding rendering and other processes, Jobs can be HUNDREDS of times faster than the same single-threaded calculations. In this example the difference is not so significant because, I think, most of the performance hit is the rendering. Also, as @naolshow pointed out: this can be further optimized.

nice content, thanks!

Why are you using that _isDone flag? Regarding the MonoBehaviour code, there are small things that can be changed in order to improve performance: 1. Using a list of enemy transforms instead of GOs, so you don't need to access the transform for the 50k enemies. 2. Grabbing the player's position before entering the loop instead of calling "_playerTransform.position" every time. 3. Using Tansform's "SetPositionAndRotation" instead of ".position" and ".rotation". 4. The following operation "direction * dt * moveSpeed" can be rearranged to improve performance like this: "dt * moveSpeed * direction" or just "direction * (dt * moveSpeed)" 5. I know Time.deltaTime is not a big deal, but I usually cache that as well. I'm not saying this is gonna beat Jobs, but it could make a difference nonetheless.

Is it a bad idea to make the thread function like an update loop? Always running in the background doing its own tasks

Give me more!!!!!

Isn't this ECS with more steps? If you're operating on a list of 'entities' as it were why not skip the job and go full ECS

cool stuff

Hi, I've seen JOB system when I started using Unity but i thought it was way too advance for me (i still do). All in all, Does this mean i cant implement JOB system into AI bots? or is there another way to optimize? Currently, I reach 20fps after spawning nearly 100 AI bots, equipped with Movement(patrol, chase many more), Combat etc. I get 15 fps with 350+ bots with their main AI script disabled. Would be greatly helpful if someone could lead me into a direction

I love it

How are you instaniating 15 thousand enemies so fast?

First

I CAN'T FKING HEAR YOU, TURN UP YOUR VOICE PLS :(((((

this video is so bad, he could make this code 10x faster with jobs but he made so many mistakes in the video lol