As im a noob in Job System, and started writing a lot of code in Jobs now.
As i have to deal with 2D Grid, so i have turned lot of helper methods into their own jobs. For example find item’s indeces. an otther job is sort those indeces etc etc
So i want to know if using jobs for these small things will actually lower the performance as i read somewhere which i assumed is that running lots of smalller jobs will keep CPU busy and draining mobile battery etc etc (something like that).
So if its True, then should i go back to my traditional way of coding and only use jobs when there is actually some complex stuff to do?
It highly depends on what your method does. If all your job does is add 5 integers, you’ll be better off doing that on the main thread. Scheduling jobs has overhead, what exactly that is you can’t measure with the current Unity tools. So you should go with your instinct and ask yourself ‘is this worth doing in another thread or not?’ You could try profiling both ways and see which way is better, but that is time consuming
It is honestly something you have to profile and get a feel for, especially on mobile. What might help you out is if you post some example process you’ve broken into small jobs and include how much data the process works on.
Am I missing something but the boilerplate with or without jobs is largely the same in ECS/DOTS land? So you kinda make things close to jobified anyway.
The real solution is to learn the Performance Testing package. Maybe you can try create a parameterized job. Then gradually increase that parameter which cause more work until the main thread lose then you know the copy+schedule+complete overhead for your job. (Still with jobs you can do something else while it is busy, etc. so a job ended up slower than main thread still has benefits.)
Personally I would say yes, because if that simpler task ended up losing benefit in a job then I can choose not to care. I get the benefit of believing that in other bigger jobs it is probably weighted out the cost of having to constantly worry if small jobs are losing out or not.
Theoretically it is a no (but theoretically). While Burst compile helps make the job faster still you will be copy data in/out with jobs and schedule/complete them. You still have to profile if that worths it or not because I don’t know how simple your job will be. You can optimize by managing the NativeArray that jobs work with instead of copy in/out.
ECS eliminates the NativeArray management since it make the job directly connected to ECS database (entity data) in a manner that parallels automatically no matter how messy the read/write dependency. But still ECS has to schedule/complete the job behind your back, just that it feels more transparent that JobComponentSystem helps you… the cost is not going anywhere and you will need to profile anyways. (If you feel that the job is suspiciously simple. I guess there is a point that you can feel that it is “probably” better in a job)
and yes im actually using Native Containers to pass and get data like NativeList etc, so i guess this will save me from copy in out as i also use persistance allocator due to nature of the project