NodeJS API Docs. #7
Description
- process.binding('natives') shows libs that are linking to native bindings so components as strings so that you can rebuild and use them on the fly
node -e 'console.log(process.binding("natives"))'
- import and require flags supply loader hooks before frozen intrinsics of the engine it self
- gets executed in a shared worker as first context inserted into the mksnapshot dump which is a binary representation of the stack machine
- in c++ written components that take a template function are out of the box compatible. nothing to write.
- you can directly interact with C structs and C ABI the magic is that the engine is able to convert C structs into Objects Dynamic on the fly. The Engine is not nodeJS it is the ESHost v8 it self which now got a component system
the trick is we pass functions arrguments and a result shared array buffer directly from the engine into the function.
so it operates on that what we call a handle represented as SharedArray Buffer it is equal to what we do in wasm implicitly
thats what we name a fast ffi call operating on sharedMemory all locking is abstracted by the engine it self no need to code your own logic.
https://github.com/bengl/sbffi shows that effect the essential part is
ffi-napi: 772.013ms <= Nodejs as alsways
sbffi: 29.467ms <= nodejs and shared arraybuffers + call lib
napi-addon: 3.790ms <= napi nativ nodejs addon
napi-addon-sb: 3.352ms <= same as above using sharedBuffer
wasm: 0.847ms <= shared array buffer lib uv of nodejs is now the blocker
js: 0.087ms <= as less nodejs envolved as possible only lib uv blocked
web-modules: 0u <= infinity faster.
that means that sbffi which is a slower implementation of this is significant faster and gets faster and faster as more engine layers we drop.
good first learning steps are attempt to use rollup in a repl to construct a new global that only contains what you need a restricted nodejs environment.
also a good learning is to code your own shims patch something in that stuff to fit your needs.