postMessage vs SharedArrayBuffer in worker_threads tradeoffs?

WHY IT MATTERS

Worker threads in Node.js run true concurrent code on multiple CPU cores, bypassing the event loop. Choosing how to share data between threads is the core performance decision: copy safety versus zero-copy speed.

STRUCTURED CLONING VIA POSTMESSAGE

postMessage deep-clones most JavaScript objects. Each message creates a complete independent copy in the worker's memory space, preventing accidental mutation. This is memory-safe: neither thread can corrupt the other's data. However, cloning large buffers or objects is expensive, involving serialization and allocation. Sending 100MB of data between threads via cloning incurs noticeable latency.

SHAREDARRAYBUFFER APPROACH

SharedArrayBuffer allows multiple threads to map the same memory region. Reads and writes are instant; there is no copy. This is critical for low-latency shared state like frame buffers or sensor streams. However, accessing shared memory is inherently racy. Two threads reading the same Uint8Array cell simultaneously can see different values if one thread writes mid-operation. This requires explicit synchronization using atomic operations: Atomics.load(), Atomics.store(), Atomics.compareExchange().

PERFORMANCE COMPARISON

For small messages (under 1MB), postMessage overhead is negligible; the safety benefit outweighs cost. For frequent tiny updates, overhead accumulates; SharedArrayBuffer is justified. For one-time large transfers, Transferable objects (e.g., transferring buffer ownership) work better than copying. For real-time synchronization (game physics, HFT algorithms), SharedArrayBuffer is mandatory.

SYNCHRONIZATION BURDEN

SharedArrayBuffer requires data structure discipline. Without atomic operations, race-condition bugs are difficult to reproduce and debug. The correct pattern uses atomic operations exclusively or message-passing for coordination. Most applications overestimate their need for zero-copy; simpler postMessage designs fail less often.