[Research] Communication steps between JS and C++ in core

[anonrig]

Hi,

I wanted to ask this issue publicly since I need to know who has more knowledge on this. I'm investigating & eager to learn the code pieces called for calling a C++ function from Javascript side of Node.js core. I'm particularly interested in how serialization & registering functions are done outside of V8 (and by us.), and how impactful each of these steps is.

The answers to these questions should and can shed some light on any performance improvements we can make. Please tag & mention the correct person and team(s) if you think they might share their experience.

cc @nodejs/startup @joyeecheung

[joyeecheung]

I think https://github.com/nodejs/node/blob/main/src/README.md already captures most of this?

[joyeecheung]

Also regarding performance: we don't really do much on top of what V8 already does for a basic C++ binding function. The serialization and registration basically comes down to placing addresses into an array before any V8 instance is created so that V8 can reassign the pointers to these external references in deserialized code. (For example, we put at index 0 the address of a C++ function at snapshot generation time, then again put the address of the same function at the same index at runtime, and V8 would replace the place holder in deserialized code to that C++ function with the address at index 0). It makes little difference at run time other than some legwork during startup, and is only done once per process, that should be fairly trivial compared to all the other things we do at startup (at least I've never seen this being noticeable in the profiles). The same thing also happens to all the V8 builtins written in C++, and what V8 does for those isn't too different from what it does for our C++ binding functions.

[anonrig]

(For example, we put at index 0 the address of a C++ function at snapshot generation time, then again put the address of the same function at the same index at runtime, and V8 would replace the place holder in deserialized code to that C++ function with the address at index 0)

Particularly these kinds of small but important things are hard to grasp and follow (IMHO). I'm trying to create a map like #44239, in order to understand if there is any room for improvement.

[joyeecheung]

This is only done for the first time the function is invoked, though, subsequent invocations will just reuse the code already compiled. I am not sure if this is the level of detail that you'd actually care about if you are looking into the performance of something as complex as fs.readFile...there are a lot more internals that would matter more than this, like whether the extensive use of primordials slow down e.g. path.toNamespacedPath(), even though overall the overhead of those would still be neglible compared to the time spent on FS operations and buffering, but at that rate even how V8 implements Function.prototype.bind would be more documentation-worthy than how the C++ pointers are matched when the code is executed for the first time, at least there are a lot of Function.prototype.bind invocations every time the function is called..

[joyeecheung]

Actually on that note, I recently noticed that path.resolve() can be quite slow, possibly due to the extensive use of primordials, and on Windows that is used for all FS operations that take paths.

[anonrig]

I just converted it to the discussion.