Quick answer: Calling Complete right after Schedule serializes the main thread with the job — you gain nothing. Schedule early, do unrelated main-thread work, then Complete (or read results next frame).

A pathfinding job is scheduled and immediately completed. The profiler shows the main thread blocked on Complete for the job’s full duration — you got serial work with extra scheduling cost.

Schedule Early, Complete Late

void Update()
{
    _pathHandle = pathJob.Schedule();          // kick off
    DoOtherMainThreadWork();              // useful work in parallel
    JobHandle.ScheduleBatchedJobs();          // hint scheduler to start

    _pathHandle.Complete();                  // wait at the end
    ApplyPath();
}

The main thread runs useful work while the worker computes. By the time you call Complete, the job is often already done — near-zero wait.

Or Defer to Next Frame

For non-urgent results (AI plans, async loads), schedule this frame and Complete next frame:

if (_pendingHandle.HasValue)
{
    _pendingHandle.Value.Complete();
    Apply(_results);
}
_pendingHandle = newJob.Schedule();

Whatever ran for a whole frame is guaranteed ready — no stall ever.

ScheduleBatchedJobs Hint

By default Unity batches scheduled jobs and dispatches them at certain sync points. Calling JobHandle.ScheduleBatchedJobs() after scheduling tells the scheduler “start now” — less waiting at Complete.

Verifying

Profiler shows main thread doing real work during job execution. The Complete call is microscopic. Frame time drops to roughly max(main work, job work).

“Schedule, do other work, complete. Schedule + immediate complete is just ‘run on main thread with extra steps’.”

Long jobs especially benefit from the next-frame pattern — one frame of latency is usually invisible; a 10ms main-thread stall is not.