daiyip

Yes in common sense.

But for node cluster's case, if we need to load a data set for a worker to serve request, it has to be loaded on each process. While the multi-threaded model will have only one copy.

JXCore is based on node codebase, while Napa.js is written from scratch with multi-threading consideration at its core. We evaluated JXCore before starting Napa.js, but found easier to re-architecture to get performance and memory sharing right.

Since everything is in a single process, they can be shared via native structures. Each JS thread has its own heap, there will be a cost to transfer the shared native structures into JS object.

For complex objects, usually JSON is used thus marshall/unmarshall is needed. But for objects like UTF-8 string or ArrayBuffer, the same layout is used across JS and C++, thus at almost no cost.

Another thing is that between addon-modules, they can pass pointer of native structures (like Buffer) using 2 uint32 through JS. In this case, JS works as a binding language.

That's correct. Think about a scenario that each worker needs to access a 1GB hash map. In node cluster, we have to load this 1GB map per process, but in the same process, all JS threads can access the map via an addon.

A key design goal is to make all workers within a zone symmetric, broadcasting/executing to specific workers is an anti-pattern. Please see: https://github.com/Microsoft/napajs/wiki/introduction#zone

Here is why napajs is started: https://github.com/Microsoft/napajs/wiki/Why-Napa.js