Node.js主进程与子进程间比IPC更快的数据交换方式探究

Great job putting together this benchmark for inter-process communication (IPC) in Node.js! Let’s break down your findings and address your question about shared memory:

Your test results highlight clear performance differences between different communication methods, which makes sense given how each works under the hood:

• fs streams (325ms)：This is the fastest option in your test, likely because Node.js has heavy optimizations for local file system operations. While it’s quick for this specific round-trip scenario, keep in mind it relies on disk (or in-memory temp files) and isn’t ideal for real-time, low-latency use cases where reliability or immediate feedback matters.
• node-shared-cache (350ms)：This library leverages shared memory under the hood, which cuts out the serialization/deserialization overhead that plagues most IPC methods. Since your test involves passing a large JS object, skipping the step of converting the object to JSON/Buffer (and back) gives it a noticeable edge over native IPC.
• Native IPC (399ms)：Node.js’s built-in parent-child process communication uses pipes under the hood. It’s reliable and requires no extra dependencies, but the mandatory serialization of JS objects into a transmittable format adds overhead that pushes it slightly behind shared memory-based solutions.
• Socket.io (1523ms)：As a network-focused library, Socket.io adds layers of protocol overhead (like TCP handshakes, packet framing, and optional encryption) that are unnecessary for local inter-process communication. It’s great for cross-machine or browser-server communication, but overkill here—hence the much higher latency.

You’re partially right that full shared scopes aren’t possible, but Node.js does support limited shared memory via the worker_threads module:

• SharedArrayBuffer: This allows main threads and worker threads to share a block of binary memory. You can serialize your JS object into a Buffer, copy it into the shared array, and then deserialize it in the worker. While it doesn’t let you share JS objects directly, it eliminates the need to copy data between processes (a big win for large payloads).
• Atomics API: Pair this with SharedArrayBuffer to safely read/write to shared memory across threads, preventing race conditions.
• No shared scopes: Each thread (whether main or worker) has its own V8 instance and execution context. Variables, functions, and module states are completely isolated—you can’t directly access a worker’s variables from the main thread, or vice versa. Communication still requires explicit message passing or shared memory operations.

It’s worth noting that node-shared-cache you tested is actually built on top of these shared memory APIs, so your benchmark already includes a practical implementation of this approach!

If raw speed for local inter-process communication is your top priority, go with a shared memory-based solution like node-shared-cache or a custom implementation using SharedArrayBuffer. For most general-purpose use cases, native IPC is more than sufficient and avoids adding extra dependencies. Socket.io should only be used when you need cross-machine communication capabilities.

内容的提问来源于stack exchange，提问作者JasperDM