Choosing Between Isolates and async/await for CPU‑Bound Work After Measuring Bottlenecks

Answer

First, examine the Dart DevTools CPU profiler timeline for your workload. If the timeline shows long, continuous synchronous blocks on the main thread that push frame rendering beyond the 16 ms budget, the event loop is the bottleneck and off‑loading to an isolate is likely beneficial. If instead you see mostly short gaps between isolates with little main‑thread work, the overhead of isolate communication dominates and keeping the work on the event loop (using async/await with occasional yields) is preferable.

Confirmed facts

• Dart DevTools CPU profiler timeline displays a bottleneck on the main thread as wide blocks that delay frame rendering; isolate message‑queue latency appears as small gaps between isolates rather than large UI stalls.
• Isolate startup latency (a few milliseconds) and the cost of copying data via isolate messages can outweigh the benefit for very short‑lived tasks; measure this with the 'Isolate spawn' and 'Message latency' tracks in DevTools.
• Dart SDK 3.x does not guarantee deterministic termination order when Isolate.kill is used; native resources acquired via dart:ffi may be released unpredictably, leading to race conditions if cleanup depends on a specific order.

Likely explanation

If the majority of frame time is spent in a single isolate’s compute function (or the UI thread’s event loop) with minimal time spent in isolate communication, the main thread’s event loop is the limiting factor and spawning an isolate can improve responsiveness. For tasks that take >10‑20 ms of pure CPU work and involve modest data transfer, spawning an isolate usually yields a net gain; for sub‑millisecond work or when data transfer is large, keeping the work on the event loop with async/await (yielding via await Future.value()) avoids overhead.

Recommended steps for this case

1. Record a CPU profile in Dart DevTools while reproducing the CPU‑intensive workload.
2. Inspect the timeline:
   • Look for long synchronous blocks on the main thread (>1 ms) that push frame time >16 ms → main‑thread bottleneck.
   • Look for frequent, short gaps between isolates (message‑queue latency) with little main‑thread work → isolate overhead dominates.
3. If the main thread is saturated:
   • Spawn an isolate for the CPU‑bound work using Isolate.spawn.
   • Pass only the necessary data (prefer typed data or transferable objects to minimize copy cost).
   • Inside the isolate, acquire any native resources via dart:ffi, perform the computation, then explicitly release those resources before sending a completion message back to the main isolate.
   • On the main side, await the completion message, then optionally send a shutdown signal; let the worker isolate exit naturally rather than relying on Isolate.kill for ordering.
4. If the main thread is not saturated but isolate communication shows high latency:
   • Keep the work on the event loop.
   • Break the work into chunks and yield control periodically with await Future.value() or await Compute.isolate? Actually use await Future.value() to allow UI frames.
   • Consider optimizing the algorithm or using SIMD/typed data to reduce per‑chunk cost.
5. For deterministic cleanup of native resources:
   • Each isolate owns its native resources and releases them internally before signaling completion.
   • Use a port‑based shutdown protocol: the main isolate sends a 'shutdown' message; the worker isolates respond with a 'done' message after cleanup, then close their port and exit.
   • Avoid using Isolate.kill for ordering; if you must terminate an isolate abruptly, ensure all native resources are wrapped in a RAII‑style destructor that is safe to call from any thread.
6. If you cannot determine whether the main thread event loop is saturated from the current profile, request the Dart DevTools CPU profiler timeline for the specific workload to confirm the bottleneck before deciding.