lib: print to stdout/stderr directly instead of using console

[joyeecheung]

lib: print to stdout/stderr directly instead of using console

This patch adds an internal function that prints to stdout or
stderr by directly writing to the known file descriptor, and
uses it internally in common cases to avoid the overhead
of the console implementation.

benchmark: add benchmark for node -p

Local benchmark results

                                             confidence improvement accuracy (*)   (**)  (***)
 misc/print.js code='"string"' dur=1                ***     10.26 %       ±1.70% ±2.26% ±2.94%
 misc/print.js code='1' dur=1                       ***     10.92 %       ±1.46% ±1.94% ±2.52%
 misc/print.js code='process.versions' dur=1        ***      9.51 %       ±1.71% ±2.28% ±2.98%
 misc/print.js code='process' dur=1                 ***     11.34 %       ±1.71% ±2.27% ±2.96%

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22577/

[joyeecheung]

Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/349/
Benchmark CI(testing): https://ci.nodejs.org/job/node-test-commit-custom-suites-freestyle/6335

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22578/

[joyeecheung]

From the CI:

14:45:30                                              confidence improvement accuracy (*)   (**)  (***)
14:45:30  misc/print.js code='1' dur=1                       ***     14.64 %       ±0.64% ±0.86% ±1.11%
14:45:30  misc/print.js code='process' dur=1                 ***     14.87 %       ±0.52% ±0.69% ±0.90%
14:45:30  misc/print.js code='process.versions' dur=1        ***     14.07 %       ±0.78% ±1.04% ±1.36%
14:45:30  misc/print.js code='"string"' dur=1                ***     14.36 %       ±0.89% ±1.19% ±1.56%

[BridgeAR]

If we have such significant overhead with console.log should we not try to improve the console performance instead? We have a lot of function calls for each console.log() that could instead return static values and we can probably simplify our current abstraction quite a bit.

[joyeecheung]

@BridgeAR I don't think we could improve console.log() this way, specifically, the overhead comes from the stream implementation which is sort of the hidden contract of Node.js's console.log() (e.g. that it uses process.stdout). There is also a trade-off when console.log() is used to print large chunks of data - for the call sites changed here that is not likely to matter though.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22673/

[joyeecheung]

I am going to land this after the 7 day wait if no more reviews come up.

[Fishrock123]

Isn't this pretty much the same as process._rawDebug()? If so, is it necessary?

[joyeecheung]

@Fishrock123 It’s not exactly the same in that the output is formatted different for compatibility (primarily colors), it handles IPC, can print to stdout, and it’s not accessible in the user land - if we change any of these to process._rawDebug() I am afraid it could be a semver-major. Also the point here is to have a lighter weight console so it needs to match the console behavior which is not so raw for process._rawDebug().

[joyeecheung]

Landed in 31b3dd2...c5817ab