Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Feedback Burst job schedule overhead
#1
Hi, I noticed huge overhead coming from scheduling jobs and I have got several questions.
First of all I am aware that pushing many large job structs is slow and waking up threads is not free, however I did not expect such a big performance difference.
You can see profiler snapshot of obi simulation scheduling, single frame has 20 substeps and for testing purposes I added callback with job handle to schedule custom job (small blue bottom column).

Observations:
1. Each following substep is longer. For example the first call takes ~0.01ms, while the last one is ~0.1ms. This is huge difference, especially for jobs like particle collision where most of update is taken by them (0.4ms single substep!).
2. Using ScheduleByRef helps a bit, but I think for my custom jobs it's maybe 20% and what is more important I can't see wh huge job structs like friction can take small fraction of frame, while scheduling my job takes several times more time even if it's smaller.
3. I expected that changing Parallel to IJobFor would give me huge boost because it does not need to wake up everything, but it's not true.
4. Calling JobHandle.ScheduleBatchedJobs(); does not change anything, or I can't see visible difference.

   

In short I fail to see what exactly is causing that and on top of that Iam worried about obi8 - if I write custom constraint I guess it will be the same, so writing like 2-3 custom scripts going to kill the frame rate.
Reply
#2
Hi!

Scheduling jobs shouldn’t be anywhere as costly as 0.1 ms per job. Not sure why you mention friction constraints as an example of a “huge” job struct: it’s quite small, only a handful of NativeArrays are passed, which consist of just 2 integers each (memory address and count). That’s hardly enough data copying to even show up in the profiler.

Make sure to disable the jobs debugger though: enabling it will result exactly in the behavior you’re getting - scheduling jobs gets slower the more jobs you schedule in a frame, specially with long dependency chains. Everything will be considerably slower overall with debugging enabled.

Kind regards
Reply