Per-request compileStreaming vs pre-compiled Module shared to workers for tail latency

No, transferring a WebAssembly.Module to workers does not guarantee that the compiled code is reused without recompilation; reuse depends on the engine and how it handles the transferred artifact.

Confirmed facts

• The WebAssembly specification defines a serializable module but provides no cross‑isolate compilation cache or performance guarantees.
• Engines may share native compiled code within a process or agent cluster, but this behavior is implementation‑specific and can change with version or flags.
• Approach A (per‑request compileStreaming/instantiateStreaming) still performs compilation, memory allocation and possible tier‑up work for each request, which can create contention under concurrency even though compilation overlaps with network transfer.
• Approach B (pre‑compile once and transfer the Module) removes repeated compilation when the engine honors transfer, but each request still pays instantiation cost: import resolution, memory/table/global allocation, and start‑function execution.

Likely explanation

When a Module is posted to a worker, the receiving engine can either deserialize the binary and reuse already‑generated native code (if it maintains an in‑process code cache) or it may treat the bytes as a fresh module and re‑compile or re‑optimize them. Because the spec does not require a cache, the outcome varies by engine (V8, SpiderMonkey, Wasmtime, etc.) and by whether the worker shares the same process/agent cluster as the main thread. Instantiation, however, always allocates per‑instance state (memories, tables, globals) and runs the start function, so even with perfect code reuse the per‑request latency can still be limited by instantiation work and any contention on shared resources such as the heap or atomics.

Steps needed for this case

1. Determine the exact engine/runtime (e.g., V8 in Chrome/Node, SpiderMonkey in Firefox, Wasmtime, Wasm3) and its version, and verify whether your workers run in the same process/agent cluster as the main thread.
2. Feature‑detect Module transfer: create a minimal Module, post it (or structuredClone it) to the target worker, confirm no DataCloneError, then instantiate it and check that exported functions behave as expected.
3. Run a closed‑loop benchmark at fixed concurrency (e.g., 50‑200 simultaneous requests) using identical module bytes served from memory or a local socket. Measure separately:
   • compile time (if any)
   • instantiation time
   • total request latency (p50, p99, p99.9)
   • CPU and memory usage
4. Include a warm‑up phase to let any tier‑up or lazy compilation settle, repeat the measurement several times, and compare Approach A (compileStreaming+instantiateStreaming per request) against Approach B (pre‑compile once, transfer Module, instantiate per request).

If you are unsure whether your workers share a process/agent cluster with the main thread, please confirm that detail, as it directly influences whether module transfer can reuse compiled code and thus affects the tail‑latency recommendation.