3 ms·
It really depends on your use case and on how you design for threads. Quite a lot of data types can be sent by postMessage, and a decent amount of them are tran
by eyelidlessness 5y ago
It really depends on your use case and on how you design for threads. Quite a lot of data types can be sent by postMessage, and a decent amount of them are transferable. If your use case doesn’t require passing around functions (and if you can’t find a way to work around that), many workloads which would benefit from multithreading in another language will likely similarly benefit from JS threads (Web Workers, Node’s Worker Threads, etc). The biggest determining factor at that point is whether the overhead of instantiating them, and of message passing, is worth it. (And the latter is often a lot less than people realize; in my experience it’s almost universally faster than crossing a WASM/FFI-type of boundary.)
- johncolanduoni 5y agoOn what engine have you seen postmessage be faster than a WASM/JS boundary? It’s at least an order of magnitude slower on Chrome/V8, even when a call needs to pass significant strings into WASM (microseconds vs hundreds of ns). It’s also worth noting that postmessage is itself an FFI boundary that requires a JS to C++ transition on every engine I’m aware of.
- eyelidlessness 5y agoI’ve seen in on Node 16 (also V8) trying both purpose-built and custom bindings to libraries built in Rust, C, C++ and Go. All of the purpose built libraries acknowledge there’s an overhead to cross the native/WASM boundary. In my experience, measuring extensively, postMessage with native runtime objects outperforms any other ser/de solution that works with JS values.