Web worker meets worker threads – threads.js
threads.js.org
threads.js.org
I tried to use workers to speed up a JS bundler/compiler system 6 years ago by farming out parsing & analysis work, and getting results back onto the main thread for my naive implementation took more CPU time than the work itself.
Deserialization costs on the main thread is one of the biggest issues we have in the Notion back-end as well - no matter how fast the DB/cache are, we’re throughout limited by JSON.parse (or equivalent). I’m thinking seriously about Arrow because we could keep data in a Dataframe instead of as JS objects, and share freely between threads without copy, but that kind of strategy would require a large codebase rethink. Much more expensive than other languages where a bit of shared memory threading can truly speed up data processing.
I've had an idea for a fun little JS game for a while now - seeing this is going to give me an excuse to build it and try workers at the same time.
Thanks for sharing!
Either way, props to OP for the great work!
Can someone explain to me how this is possible? It seems dubious.
Anything that could attack from the main thread would have access to the source and the communication channel with both the input and output of this thread. Technically, the thread would be protected - but that doesn't seem to be the attack vector.
If they are not awaited, someone has to manage an array/list of promises.
Is there a worker model where the worker can work on a series of tasks?
In a Node web server process, though, this isn't really true. If you perform a CPU intensive task on the main event loop, all other incoming requests will pause. Using worker threads instead turns that CPU task into, for all intents and purposes, an async io call, freeing the main event loop to handle concurrent incoming requests.
Since handling CPU intensive tasks is the main downside of a Node web app, I think this library is a great solution for that (I think this library's API is a much easier to use wrapper around native Worker threads).
Tried to use them with Node Canvas a few months ago but it’s not context aware[1] so had to go back to forking processes.
Intriguing to see someone in this thread say they already work with TFjs.
There is parallel.js, which allows you to just pass your task as a function:
p.spawn(someFunc, someArg)
It's unfortunate that there's no way to to just "run this function in the background" like so many other languages has. Filip Pizlo explored what it would take: https://webkit.org/blog/7846/concurrent-javascript-it-can-wo... , it's technically doable at least for JSC but is unlikely to ever happen.
Anyways background computation is one of the weakest parts of JavaScript. Happily wasm threads don't have the same limitations and so can take over.
I had a pretty clear use-case: running a cpu-hungry ML model at 5-10 FPS without locking a dynamic UI that needed to stay around 60fps.
I tried out all the various worker libraries: thread.js, comlink, etc. What I found is that while these libraries do make it easier to get a worker up and running, they introduce abstractions that make it harder to achieve the goal of using workers in the first place: performance.
The browser APIs for WebWorkers are not difficult to learn and use. But stashing code into a worker doesn’t magically solve performance issues. It’s just the first step.
In my case, I had to optimize the transfer of data to and from the worker. Any abstraction that sits in front of that transfer ends up being at best being an additional and unnecessary cognitive load, and at worst being an obstacle to my original goal of improving performance. While I’m sure these libraries take pains to ensure they don’t do anything that might impact performance, the slightest possibility of a library’s contribution to degraded performance means that your cognitive load now includes ensuring the library is performant too.
It’s analogous to hunting down a tricky bug. Whenever I get a bug that is particularly hard to understand, I end up performing dramatic (albeit temporary) surgery on the codebase to remove anything extraneous to the bug. If I can remove 95% of the code, then I only need to think about 5% of the code. While it is true that the code I removed had nothing to do with the bug, my eyes and brain have an easier time ignoring code that doesn’t exist rather than code that doesn’t matter.
Same for these worker libraries. It’s more code that you have to consider. And if you are using a worker for a good reason — to solve a hard performance issue — you really don’t want to have to consider any more lines of code than absolutely necessary, and ideally you only have to consider lines you’ve written yourself.
I’m not usually in the camp of “write everything yourself”, but leveraging WebWorkers for performance is one of those cases where you are going to get your hands dirty anyway. You might as well embrace it from the start.
Now, if you already understand workers inside and out, then these libraries probably would save you time and be less bug-prone in handling thorny use-cases like workers that run in isometric codebases. Ironically, those who least need a library gain the most from it, while those who most need a library gain the least from it.
it's really simple and offloads lots of stuff from the ui which can than have a nice looking upload spinner. (but we reduce what we transfer to the worker, btw. you can easily send a file handle)