Description
v10.5.0 has a new worker_threads module that allows pure JS functions to run on a separate thread. The node-cpp-skel demonstrates doing this type of thing using C++, but the worker_threads module allows for it in pure JS. (https://nodejs.org/en/blog/release/v10.5.0/)
It would be useful to try to write an 🍏 to 🍏 (or as close as we can get) comparison benchmark of doing the same work in C++ threads vs JS threads using worker_threads. We would try to answer questions like:
- 🍒 Is performance of passing data (Enhancement: pass data created in threadpool back to main JS thread in zero-copy way #69, Enhancement: pass data from node::Buffer into threadpool #67) similar in with
worker_threadsvs using libuv directly in C++? - 🍊 When combined (overhead of thread queuing, passing data to the thread, doing compute, getting data back) which approach is faster?
We could get at 🍒 by writing a benchmark that passes the same, large data, and does no compute in the thread. Instead that thread could just sleep for N seconds.
We could get at 🍊 by passing the same data and doing the same (as close as possible) compute, perhaps a Fibonacci (or some kind of classical compute intensive workload).
Depending on the results we will want to update https://github.com/mapbox/cpp/blob/master/node-cpp.md#why-create-a-node-addon which says:
Why create a node addon?
To port a C++ project to Node to expose a new interface for the tool (like Mapnik & Node Mapnik)
Improve performance at scale where Node becomes the bottleneck (i.e. concurrency)
If JS is just as fast as C++, then we'll want to update that doc to mention worker_threads as a more ideal solution than writing a node addon to access the thread pool. If JS/worker_threads is slower than C++ then we'll probably want to add details to that doc about what types of workloads or performance situations we'd want to use C++ and which we'd want to consider JS/worker_threads
/cc @mapbox/core-tech