Unity job system is not working as expected

I'm learning unity DOTS technology and tried to create a small project which instantiates some prefab and moves it to the final target. project is simple but my issue is the performance. my code is running faster in old mono implementation then the new DOTS implementation. how is this possible? I know that in some situations may mono run faster but in my case it should not but still, I'm not getting where I'm doing wrong.
I have attached my code and some screenshots please someone helps me to find where I'm doing something wrong?

Code (CSharp):

1. using System.Collections.Generic;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using UnityEngine.Jobs;
5. using Unity.Collections;
6. using Unity.Jobs;
7. using Unity.Burst;
8. using Unity.Entities;
9. using Unity.Mathematics;
10.  
11. public class CubeMovementJob : MonoBehaviour
12. {
13.     public Transform gameObjectToBeInstatiated;
14.     public int count = 2000;
15.     public float speed = 20;
16.     public int spawnRange = 50;
17.     private Transform[] transforms;
18.     private float3[] targets;
19.     private List<Transform> cubes;
20.     public bool useJob;
21.  
22.     // Start is called before the first frame update
23.     void Start()
24.     {
25.         transforms = new Transform[count];
26.         cubes = new List<Transform>();
27.  
28.         for (int i = 0; i < count; i++)
29.         {
30.             Transform objTransform = Instantiate(gameObjectToBeInstatiated, Vector3.zero, Quaternion.identity);
31.             cubes.Add(objTransform);
32.             transforms[i] = objTransform;
33.         }
34.  
35.         targets = new float3[transforms.Length];
36.         for (int i = 0; i < targets.Length; i++)
37.         {
38.             targets[i] = new float3(UnityEngine.Random.Range(-spawnRange, spawnRange), UnityEngine.Random.Range(-spawnRange, spawnRange), UnityEngine.Random.Range(-spawnRange, spawnRange));
39.         }
40.     }
41.  
42.     // Update is called once per frame
43.     void Update()
44.     {
45.         if (useJob == true)
46.         {
47.             NativeArray<float3> nativeTargets = new NativeArray<float3>(targets, Allocator.TempJob);
48.             TransformAccessArray transAccArr = new TransformAccessArray(transforms);
49.  
50.             MovementJob job = new MovementJob
51.             {
52.                 deltaTime = Time.deltaTime,
53.                 Targets = nativeTargets,
54.                 Speed = speed
55.             };
56.  
57.             JobHandle newJobHandle = job.Schedule(transAccArr);
58.  
59.             newJobHandle.Complete();
60.             transAccArr.Dispose();
61.             nativeTargets.Dispose();
62.         }
63.         else
64.         {
65.             for (int i = 0; i < targets.Length; i++)
66.             {
67.                 cubes[i].position = Vector3.Lerp(cubes[i].position, targets[i], Time.deltaTime / speed);
68.             }
69.  
70.             // This is just to simply give some extra task in order to check the performance difference.
71.             float value = 0f;
72.             for (int i = 0; i < count; i++)
73.             {
74.                 value = math.exp10(math.sqrt(value));
75.             }
76.         }
77.     }
78. }
79.  
80. [BurstCompile]
81. public struct MovementJob : IJobParallelForTransform
82. {
83.     public float deltaTime;
84.     public float Speed;
85.     public NativeArray<float3> Targets;
86.     public void Execute(int index, TransformAccess transform)
87.     {
88.         transform.position = Vector3.Lerp(transform.position, Targets[index], deltaTime / Speed);
89.  
90.         // This is just to simply give some extra task in order to check the performance difference.
91.         float value = 0f;
92.         for (int i = 0; i < Targets.Length; i++)
93.         {
94.             value = math.exp10(math.sqrt(value));
95.         }
96.     }
97. }
98.  
99.  
100.  

Above Images: Framerate without job system (avg 135fps).



Above Image: Framerate with job system implementation (avg 108fps).

Even though my movementjob is running parallelly why I'm not getting the extra performance at least more than the old mono behaviors implementations?

 

You should profile in a build to get the real numbers, not inside the Editor.

 

Try deactivate safety checks and burst debugger.

And the code is not the same in the 2 scenarios, in mono you run the "extra cost" loop once, in the job for each transform!

 

Ya but even in editor it cannot show this much performance error and also here I'm looking for a massive performance change.
and also just now I tested on mobile the result is the same as in editor I mean almost similar still job system implementation is lagging then older mono implementation.

 

I tried that but it dint effect anything.

 

In your profile the actual work seems to really fast at around 0.08ms. I guess the setup code is slower.

1. Add profiling sections
2. Try using the TransformAccessArray constructor receiving a Transform[] instead of using Add
3. Reuse your TransformAccessArray. (TransformAccessArray.SetTransforms)

 

The mono code should this:

Code (CSharp):

1.  
2. for (int i = 0; i < targets.Length; i++)
3. {
4.         cubes[i].position = Vector3.Lerp(cubes[i].position, targets[i], Time.deltaTime / speed);
5.  
6.         // This is just to simply give some extra task in order to check the performance difference.
7.         float value = 0f;
8.         for (int i = 0; i < count; i++)
9.         {
10.             value = math.exp10(math.sqrt(value));
11.         }
12. }
13.  

 

Code (CSharp):

1. using System.Collections.Generic;
2. using UnityEngine;
3. using UnityEngine.Jobs;
4. using Unity.Collections;
5. using Unity.Jobs;
6. using Unity.Burst;
7. using Unity.Entities;
8. using Unity.Mathematics;
9.  
10. public class CubeMovementJob : MonoBehaviour
11. {
12.     public Transform gameObjectToBeInstatiated;
13.     public int count = 2000;
14.     public float speed = 20;
15.     public int spawnRange = 50;
16.     private Transform[] transforms;
17.     private float3[] targets;
18.     private List<Transform> cubes;
19.     public bool useJob;
20.     TransformAccessArray transAccArr;
21.     // Start is called before the first frame update
22.     void Start()
23.     {
24.         transforms = new Transform[count];
25.         cubes = new List<Transform>();
26.  
27.         for (int i = 0; i < count; i++)
28.         {
29.             Transform objTransform = Instantiate(gameObjectToBeInstatiated, Vector3.zero, Quaternion.identity);
30.             cubes.Add(objTransform);
31.             transforms[i] = objTransform;
32.         }
33.         transAccArr = new TransformAccessArray(transforms);
34.         targets = new float3[transforms.Length];
35.         for (int i = 0; i < targets.Length; i++)
36.         {
37.             targets[i] = new float3(UnityEngine.Random.Range(-spawnRange, spawnRange), UnityEngine.Random.Range(-spawnRange, spawnRange), UnityEngine.Random.Range(-spawnRange, spawnRange));
38.         }
39.     }
40.  
41.     // Update is called once per frame
42.     void Update()
43.     {
44.         if (useJob == true)
45.         {
46.             NativeArray<float3> nativeTargets = new NativeArray<float3>(targets, Allocator.TempJob);
47.  
48.             MovementJob job = new MovementJob
49.             {
50.                 deltaTime = Time.deltaTime,
51.                 Targets = nativeTargets,
52.                 Speed = speed
53.             };
54.  
55.             JobHandle newJobHandle = job.Schedule(transAccArr);
56.  
57.             newJobHandle.Complete();
58.             nativeTargets.Dispose();
59.         }
60.         else
61.         {
62.             for (int i = 0; i < targets.Length; i++)
63.             {
64.                 cubes[i].position = Vector3.Lerp(cubes[i].position, targets[i], Time.deltaTime / speed);
65.             }
66.  
67.             // This is just to simply give some extra task in order to check the performance difference.
68.             float value = 0f;
69.             for (int i = 0; i < count; i++)
70.             {
71.                 value = math.exp10(math.sqrt(value));
72.             }
73.         }
74.     }
75.  
76.     private void OnDisable()
77.     {
78.         transAccArr.Dispose();
79.     }
80. }
81.  
82. [BurstCompile]
83. public struct MovementJob : IJobParallelForTransform
84. {
85.     public float deltaTime;
86.     public float Speed;
87.     public NativeArray<float3> Targets;
88.     public void Execute(int index, TransformAccess transform)
89.     {
90.         transform.position = Vector3.Lerp(transform.position, Targets[index], deltaTime / Speed);
91.  
92.         // This is just to simply give some extra task in order to check the performance difference.
93.         float value = 0f;
94.         for (int i = 0; i < Targets.Length; i++)
95.         {
96.             value = math.exp10(math.sqrt(value));
97.         }
98.     }
99. }
100.  
101.  

Yess finally reusing TransformAccessArray boosted my performance, but now I'm getting avg 150fps using the job system before it was avg 108fps. thank you for the advice.

But still, I was hoping for some extra performance as my jobs are running parallelly across the multiple cores, because still, my old mono implementation and my job system implementation doesn't have any much performance gap, is this the final performance gain for this code is there anything still I can optimize so that I can get that expected boost. because in some videos I saw that code running in old mon implementation was taking around 80ms but after implementing a job suddenly it just took around 1ms for that same work. so I was expecting that kind of performance boost here.

 

If you are looking for the best possible performance you should take a look into the complete DOTS workflow (ECS + Jobs + Burst).

 

As I mentioned already, your mono has less work as the job version, so it is not comparable.

You could also try increasing the number of objects.

 

How? I dint get that because in both job and mono the same set code is getting executed. but In mono 2 for loops are running sequentially one after another but the job is running parallelly but still why my job is not getting that high-performance boost?

 

There is not alot to gain, the majority of the frame time is taken up by other stuff:
You had a frametime of 7.5 ms and the profiler shows 1.3ms in your C# implementation. Getting that to 0 would give you 160fps. These times are much too low to be safe in editor.
Increase your object count to 20k-200k and use objects without renderers if you want to have a more accurate performance comparison.

@runner78 is right, the work isn't the same as your 'extra task' is acutally executed 2000 times in the jobified version vs 1. in the C# version. But the bursted code is so fast this isn't really important here. The parallelfor jobs are actually done with all the work after only 0.08ms.

 

ya, I get that. but please don't mistake me I'm still not satisfied with the performance in job+burst in my code. I think I'm doing something wrong or can someone give the full technical explanation of why my job performance is similar to the mono performance even though job is running parallelly?

 

okay, I got your point my second for loop is running in all the 2000 jobs but in mono only once it is running for the update. but I have removed that also now code looks like this

Code (CSharp):

1. using System.Collections.Generic;
2. using UnityEngine;
3. using UnityEngine.Jobs;
4. using Unity.Collections;
5. using Unity.Jobs;
6. using Unity.Burst;
7. using Unity.Entities;
8. using Unity.Mathematics;
9.  
10. public class CubeMovementJob : MonoBehaviour
11. {
12.     public Transform gameObjectToBeInstatiated;
13.     public int count = 2000;
14.     public float speed = 20;
15.     public int spawnRange = 50;
16.     private Transform[] transforms;
17.     private float3[] targets;
18.     private List<Transform> cubes;
19.     public bool useJob;
20.     TransformAccessArray transAccArr;
21.     // Start is called before the first frame update
22.     void Start()
23.     {
24.         transforms = new Transform[count];
25.         cubes = new List<Transform>();
26.  
27.         for (int i = 0; i < count; i++)
28.         {
29.             Transform objTransform = Instantiate(gameObjectToBeInstatiated, Vector3.zero, Quaternion.identity);
30.             cubes.Add(objTransform);
31.             transforms[i] = objTransform;
32.         }
33.  
34.         transAccArr = new TransformAccessArray(transforms);
35.         targets = new float3[transforms.Length];
36.  
37.         for (int i = 0; i < targets.Length; i++)
38.         {
39.             targets[i] = new float3(UnityEngine.Random.Range(-spawnRange, spawnRange), UnityEngine.Random.Range(-spawnRange, spawnRange), UnityEngine.Random.Range(-spawnRange, spawnRange));
40.         }
41.     }
42.  
43.     // Update is called once per frame
44.     void Update()
45.     {
46.         if (useJob == true)
47.         {
48.             NativeArray<float3> nativeTargets = new NativeArray<float3>(targets, Allocator.TempJob);
49.  
50.             MovementJob job = new MovementJob
51.             {
52.                 deltaTime = Time.deltaTime,
53.                 Targets = nativeTargets,
54.                 Speed = speed
55.             };
56.  
57.             JobHandle newJobHandle = job.Schedule(transAccArr);
58.  
59.             newJobHandle.Complete();
60.             nativeTargets.Dispose();
61.         }
62.         else
63.         {
64.             for (int i = 0; i < targets.Length; i++)
65.             {
66.                 cubes[i].position = Vector3.Lerp(cubes[i].position, targets[i], Time.deltaTime / speed);
67.             }
68.         }
69.     }
70.  
71.     private void OnDisable()
72.     {
73.         transAccArr.Dispose();
74.     }
75. }
76.  
77. [BurstCompile]
78. public struct MovementJob : IJobParallelForTransform
79. {
80.     public float deltaTime;
81.     public float Speed;
82.     public NativeArray<float3> Targets;
83.     public void Execute(int index, TransformAccess transform)
84.     {
85.         transform.position = Vector3.Lerp(transform.position, Targets[index], deltaTime / Speed);
86.     }
87. }
88.  
89.  

but still, both my mono performance and job+burst performance are almost the same just my jobs+burst is leading by just 10-15fps on an average.

 

Ignore your fps. Open the profiler and compare the time spend in CubeMovementJob.Update. That is what you are currently interested in.

 

If you reduce the amount, you will get to a point where mono is getting faster as jobs.
If you increase the amount, you will see the real performance boost for burst.

 

On top of what other people have said, while continuing to use gameobjects you wont see significant improvements compared to ditching them and only manipulating entities. Being able to use gameobjects with dots is more of a compatibility and ease of use thing rather than performance goal for unity. If you got a 80x speedup just using jobs to access gameobjects there would be a lot less impetus for unity to roll out the dots native ecosystem. That video you saw most likely compares pure entities to gameobjects, although if it doesn't I'd surely like to see it.

 

If you aren't ready for dots, but want to be able to take advantage of the jobs/burst system, just create some nativearrays to handle position, rotation, scale, matrix4x4 (you need a job to output to the matrix4x4), skip gameobjects and transforms... then you can draw those with drawmeshinstanced on the main thread and manipulate the position/rotation in another job... you will see ridiculous performance (possibly ludicrous speed). I've got a simulation that outputs a bunch of AIs with collision and pathing, targetfinding and animation running with 100,000 actors at 50-60FPS on a 4 core machine, without using DOTS.

If you need to debug just have a gameobject with a script that outputs or draws data/lines on the scene view to debug positions in realtime, obviously that will be a performance hit but its something you would only turn on to debug a couple thousand objects, you wouldn't want that output on more than 1-2 thousand at a time.

 

Above image: performance with job+burst.

Above image: performance in old mono implementation.

I got your point, but fps is directly proportional to profiler performance stats, right?
I can see that in profiler my job+burst implementation taking less time to execute a script then in mono. but what else is taking extra time? as you can see in job+burst implementation executing the script is around 0.40ms but in mono, it is taking 1ms. so there is almost 0.60ms performance increment in job+burst implementation but why still I'm getting fps almost similar to the mono implementation itself. is stats have any error (I'm excluding editor loop here).

my object is just unity primitive cube and a small texture I have added nothing else.

 

with the same implementation, I have tried with instantiating 10000 objects but in both mono and burst+job implementation I got the same fps results in my pc, it was around 25fps in both jobs and without a job test.
Then I have tried with 100000 objects there are also I got the same result around 3fps with or without a job.

 

https://unitycodemonkey.com/video.php?v=C56bbgtPr_w

this is the video link which I have referred where he is getting massive performance boost just after using job+burst
and also my implementation is almost similar to his and in my implementation code is somewhat more optimized then his code for job(i have posted my recent code as reply to @julian-moschuering) as you can see that in my code inside update im reusing "TransformAccessArray" but in his implementation for each update, he is creating a new array. but still why my project is lagging? in his video, you can see that in performance with and without job implementation there is a massive difference in fps, why I'm not able to see that difference in my case?

 

found the reason: he does the math.exp10(math.sqrt(value)) 1000x per transform, which yours doesnt do(in the non job part).

also note you should use mathematic's math.lerp which is better optimized for burst

 

Okay, I got it he added this loop inside another loop if I implement that even I got the same performance gap. so only if we do that kind of heavy calculation then only we can see the performance gap between job and nonjob implementations otherwise as in my case I was moving game objects using with or without a job but I was not able to see that much performance gap between the two implementations. what I amaze is that if I instantiate some 10000 objects and move them using a job and without a job, at that time I should see that massive performance gap right? as in job, more than one object will be moved parallelly but in old mono implementation one by one we have to move per update but still why can't I see that much performance boost in job implementation?

 

https://drive.google.com/open?id=1l8WWSljTT_Wxy1CA52c4KIgcXayIImj0
I have attached a video of my project, I found a strange behavior here.
can someone explain to me why I'm getting this result?

as you can see I have a job and nonjob implementation to move my instantiated game objects.
I was instantiating 2000 game objects and moving them with both job or nonjob implementation (either job or nonjob implementation will run at a time as I have a bool variable to switch between the implementations) but the performance is almost same as you can see that fps count doesn't have many gaps between both the implementations.
But when I disable my prefab (which we are instantiating at a run time) mesh renderer and box collider components then suddenly you can see that there is a massive fps count gap between job and nonjob implementation. where job implementation is leading by around 400fps. how is that possible? for both of the implementations, I was using the same cube prefab so what made the job take that much fps gap over old mono implementations once just after removing those 2 components from the prefab which I was instantiating?

 

In you last screenshot jobs version 0.3ms, mono 1ms. Is more then 3x faster.
I think your problem is the rendering, you see in the CPU usage section, the rendering is in both over 3ms. Your graphic card is the limit factor.

 

I'm using Nvidia GeForce gt 610 of 2gb. is that not enough to render the primitive cubes?
I get that this does not issue with the jobs as you said it is because of rendering. is my graphics card is useless or can I make any further optimization?, further optimization is no possible as however I'm using a primitive cube and I have disabled many of the fields which are not required in mesh renderer component but still why this issue to just render 2000 cubes?

 

There is a lot more to rendering a frame than updating the position. Executing culling and drawing for 2000 objects, updating transform hierarchies. Handling input.. Doing the present and API calls, draw state updates... some parts of this can be improved using dots for rendering too, but that is far more intrusive when optimizing an existing application.

The part you are using jobs+burst now is 3x faster. That is what you wanted to know. When doing stuff without TransformAccessArray the benefit should be even bigger, but 3x is great.

Now: create a standalone build and profile the same function there.

 

My wrong, the CPU part of rendering is the problem, and also the physics with around 2.5ms is higher then your scripts.
Can you test the scene without transforming? Has you activated the GPU instancing in the material?

 

yes GPU instancing is enabled in material.


this is the screenshot of the profiler when I commented on the object movement part of the code, just I have instantiated 2000 cubes I'm not moving it.

 

why fps shown in profiler and unity stats are different even though the execution time is almost similar?.
as you can see that in unity stats fps shown is 158 but in the profiler, spikes are going up then 30fps according to profiler frame rate is in between 15-30fps. even though the execution time in stats is 6.3ms and in the profiler, it is 6.72 for player loop which is almost similar. why this error in unity stats? which one is showing proper stats here profiler or stats window?
if any one of the stat is wrong then why that issue is still persisting?

 

In the profiler you show a specific recorded frame, the stats display the current frame rate. Frame rates are usually the average of the last frames.

 

Okay, as you said unity stats windows show the average frame rate but how is it showing average frame rate of 150fps? as we can see that in profiler the whole execution(rendering + script execution + physics etc) graph is above the 60fps limit. and also consistently spikes are going even up 30fps range so by looking at profiler graph one can say the average frame rate is around 40fps. is that right?

 

I don't know if the editor stats updated the frame rate also in pause mode?

 

No they dont.

 

I have now tested it myself, and yes, the will continue to be updated.
I tested with 2019.3f5 and HDRP default sample scene, Play ~130fps, pause ~180fps.

 

i guess it is not possible, what you said will happen only if you come back to the idle mode from play mode. when you are in play mode and if you directly press the pause button(without coming out of the play mode) then unity will just pause it won't update anything to stats. for example, if you are there in play mode and unity stats was showing you 60fps then if you press pause button unity stats will remain in 60fps itself, but if you come out of play mode then unity automatically resets to some fps I don't know on what basis but in nonplay mode stats is showing me 175fps.

 

No, in pause the frame rate is updated continuously, frame rate is not constant and you see stats constantly changed.

 

in my editor, it is not constantly changing fps counts in pause mode.

you can see in this video below, it is my pc screen recording.
https://drive.google.com/open?id=1IqVmVzd4W3cY-7bj4vkbe5nnRRRm9_6S

 

On my machine the stats always updated also in editor mode.