Renderer unresponsiveness during large ipcMain dataset transfers

An Electron application needs to move a large analytical dataset from the Main process to a Renderer process for visualization. The current design sends the complete array through ipcMain and ipcRenderer, relying on JSON serialization across the Mojo-based IPC bridge. The goal is to identify the precise point where this pattern stops scaling and requires a different transport strategy.

Relevant constraints include avoiding synchronous IPC to prevent deadlocks, keeping the Main process responsive during serialization, and maintaining a secure preload boundary via contextBridge. A pull-based chunking model is one option, but it introduces protocol complexity. Binary formats using Uint8Array or SharedArrayBuffer may reduce overhead, yet the threshold where they outperform standard messages is not clearly documented.

Because behavior varies by Electron version and platform memory limits, current verification is required. At what dataset size or transfer frequency does JSON-serialized IPC become the dominant bottleneck compared to typed arrays or shared memory? How does the Renderer event loop behave when a large message arrives while a heavy render is in progress? What measurement approach reliably isolates Main process blocking time during these transfers without using sendSync?