Fastest JavaScript engines and runtimes to read standard input stream and write standard output stream

fastest_io.md

(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.