child_process: improve ipc performance

[mscdex]

These commits reduce/improve nextTick() usage in the child_process IPC implementation.

I should point out that I wasn't sure if we should ever need nextTick() when receiving/emitting messages, so for now I just made sure that both all internal messages and only the first non-internal message in a group are emitted within the same tick.

There is a substantial performance improvement when removing nextTick() altogether for emitted messages. My thought was that these messages should always happen on at least the next tick anyway, so perhaps it would be safe to remove it completely? All tests pass with nextTick() completely removed from handleMessage().

Results with the current changes with the included benchmark:

 improvement confidence p.value
cluster/echo.js n=100000 sendsPerBroadcast=1 payload="object" workers=1 15.62 % *** 1.440552e-08
cluster/echo.js n=100000 sendsPerBroadcast=1 payload="string" workers=1 18.59 % *** 3.478095e-10
cluster/echo.js n=100000 sendsPerBroadcast=10 payload="object" workers=1 25.71 % *** 6.436977e-26
cluster/echo.js n=100000 sendsPerBroadcast=10 payload="string" workers=1 33.88 % *** 1.812799e-22

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

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

• child_process

[refack]

Shave off a few more millis with const INTERNALPREFIX_LENGTH = INTERNAL_PREFIX.length

[mscdex]

Again, I know it can be simplified and probably optimized, but I opted to leave it as-is for now.

[refack]

[question] since internal messages are rare, will adding a Object.hasOwnProperty(message, 'cmd') && fail faster than typeof message.cmd === 'string'?

[mscdex]

I know this could be simplified but I opted to leave it as-is for now.

[refack]

Why not check for isInternal on the raw chunk?

[mscdex]

It has to be parsed first. chunks here is just an array of (complete) JSON strings.

[refack]

I meant implement a string based check. Can't we assume "innerMessages" will have a {cmd: NODE_ prefix? or at least include a , cmd: NODE_ substring? Might also be able to distinguish between three cases: user/inner/inner_with_handle, and turn the following compound if into a switch

[mscdex]

I'd rather not make assumptions about JSON.stringify() output.

[refack]

even if we don't do a string based check, returning 0,1,2 (for user / inner / NODE_HANDLE) will enable using a switch in L466

[mscdex]

It's unlikely it'll matter much, I'll let someone else work on it if they want. My main focus on this PR is nextTick() usage.

[refack]

@mscdex Thanks for the answers 🎩

[mscdex]

Results with V8 5.9 now in master:

 improvement confidence p.value
cluster/echo.js n=100000 sendsPerBroadcast=1 payload="object" workers=1 11.22 % *** 4.196927e-10
cluster/echo.js n=100000 sendsPerBroadcast=1 payload="string" workers=1 14.63 % *** 4.344752e-10
cluster/echo.js n=100000 sendsPerBroadcast=10 payload="object" workers=1 17.93 % *** 1.171912e-15
cluster/echo.js n=100000 sendsPerBroadcast=10 payload="string" workers=1 26.25 % *** 6.978421e-19

[bnoordhuis]

Nice optimization, LGTM.

[bnoordhuis]

Nothing wrong with this but you could ES6-ify it with for (const worker of Object.values(cluster.workers)). Whatever your preference.

I suppose it could even be a little faster because Object.values() doesn't walk the prototype chain but that's probably only a marginal benefit (and I didn't test so my intuition might very well be wrong.)

[mscdex]

FWIW I literally copied it from the cluster docs. I know we were trying to be more on the conservative side when it comes to introducing ES* features to benchmarks because of possible incompatibilities with older branches. For example, Object.values() does not exist in node v4.x or v6.x (although it's apparently behind a flag in recent v6.x releases).

[MylesBorins]

should this land in LTS? If so it will need to bake a bit longer.

Please change labels as appropriate