Why does my job-driven batch position update tank FPS?

Schedule cost dominates if you schedule per entity. Batch into one IJobParallelForTransform with all transforms. Set inner batch size 32-128 to match worker thread granularity.

Inner batch size impact?

Too small: high overhead per work unit. Too large: poor work distribution. 32-128 is a typical sweet spot for transform updates; profile to confirm.

Schedule then complete same frame?

Schedule in Update, complete in LateUpdate. Lets the job finish on a worker while game logic continues; main-thread waits if any.

Fix: Job-Driven Position Update Tanks FPS

Quick answer: One IJobParallelForTransform job per frame. Inner batch size 64. Schedule Update, Complete LateUpdate.

Crowd of 1000 NPCs each scheduling its own job. FPS drops below 30. Schedule overhead dwarfs the actual work.

The Fix

[BurstCompile]
struct MoveAll : IJobParallelForTransform {
    [ReadOnly] public NativeArray<float3> Velocities;
    public float Dt;
    public void Execute(int i, TransformAccess t) {
        t.position += (Vector3)(Velocities[i] * Dt);
    }
}

// Manager
void Update() {
    _handle = new MoveAll { Velocities = vel, Dt = Time.deltaTime }
              .Schedule(_transforms, 64);   // inner batch 64
}
void LateUpdate() { _handle.Complete(); }

Single schedule, parallel execution across the worker pool. Profiler shows worker time fully utilized, main thread freed.

Verifying

1000 NPCs at 60fps. Profile: physics worker busy, main thread idle on the job time.

“One job. Batch size sane. FPS holds.”

Related Issues

For NativeArray dispose, see dispose. For IJobParallelForTransform stride, see stride.

One job. Workers parallel.