4 ms·
> Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to dis
by zamalek 1y ago
> Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to discover they’ve tripled the CPU load in the main thread.
Why not use structuredClone to communicate with the worker? So long as your object upholds all the rules you can pass it into postMessage directly.
- hinkley 1y agoStructured clone only gets you a new object in this heap, not a new object in an isolate. You’re still doing stringify/parse under the hood every time you sendMessage.
- zamalek 1y agopostMessage uses it transparently: https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
- hinkley 1y agoSo I wonder if any of these improvements could be applied to structuredClone. Benchmarks aren’t showing structuredClone favorably versus JSON round tripping. Likely because JSON-compatible data structures are less complex than clonable data. I suspect with this change JSON will now be faster than structuredClone.
- zamalek 1y ago> Benchmarks aren’t showing structuredClone favorably versus JSON round tripping. Which ones? Structured clone seems to be approximately the same as FF according to this (structuredClone is slightly faster on my machine, probably margin of error): https://measurethat.net/Benchmarks/Show/23052/0/structuredclone-vs-jsonparse-jsonstringify https://measurethat.net/Benchmarks/Show/23052/0/structuredcl... (Linux: FF 141, Chromium 138).
- hinkley 1y agoSo think about how that graph is going to look once the stringify part is twice as fast. Instead of being slightly faster it'll be statistically slower.