(index)
0 'nm_qjs' 0.1335
1 'nm_bun' 0.2385
2 'nm_deno' 0.2599000000059605
3 'nm_nodejs' 0.3421999999880791
4 'nm_spidermonkey' 0.39459999999403955
5 'nm_d8' 0.4187999999821186
6 'nm_tjs' 0.4192000000178814
Send 1 MB of JSON (1048576 bytes) to the engine or runtime. Echo the JSON back to the client.
QuickJS script https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_qjs.js. The only script among the lot which reads 1 MB in one (1) read.
Node.js, Deno, and Bun use the same script https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_host.js. What I could come up with for a close to 1:1 test between Node.js, Deno, and Bun using the same API's - because ECMA-262 does specify reading standard input streams, writing standard output streams, or handling standard error stream, each JavaScript engine and runtime process I/O differently, if at all.
GNU head
or QuickJS is used to read stdin
to V8's d8
, becuase readline()
tries to execute input to d8
https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_d8.js.
To get around SpiderMonkey js
readline()
implementation, we use a RegExp
to process stdin
to the shell https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_spidermonkey.js.
txiki.js is slowest, even slower than d8
shell, where we use a subprocess to read stdin
https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_tjs.js.
V8's d8
and SpiderMoney's js
shells were not really intended to be used as a general mechanism for reading arbitrary stdin
,
they generally are expecting a TTY to input JavaScipt on the command line, and execute the JavaScript. At least we have something to bend
to our will with os.system()
in d8
, and a multi-line RegExp
in js
.
Cheers.