process: improve nextTick performance

[mscdex]

                                               confidence improvement accuracy (*)    (**)   (***)
 process/next-tick-breadth-args.js n=10000000        ***     17.11 %       ±2.80%  ±3.74%  ±4.89%
 process/next-tick-breadth.js n=10000000             ***     40.88 %       ±2.72%  ±3.62%  ±4.71%
 process/next-tick-depth-args.js n=7000000           ***     21.87 %       ±2.18%  ±2.92%  ±3.82%
 process/next-tick-depth.js n=7000000                ***     23.58 %       ±7.60% ±10.12% ±13.17%
 process/next-tick-exec-args.js n=4000000            ***     39.07 %       ±1.88%  ±2.51%  ±3.28%
 process/next-tick-exec.js n=4000000                 ***     44.92 %       ±1.67%  ±2.23%  ±2.91%

Checklist

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

[nodejs-github-bot]

@mscdex sadly an error occured when I tried to trigger a build :(

[mscdex]

These were changed to match those found in the other breadth benchmarks and it also seems to provide more stable results.

[apapirovski]

The fact that we’re emitting one object on init and then pushing another on the next tick queue goes against basic expectations of using async hooks and what the resource is supposed to represent.

[mscdex]

Since there are some that believe this should be semver-major, ping @nodejs/tsc

[mscdex]

ping?

[mcollina]

In the context of exposing the current async resource rather than just exposing the asyncId, this change might require to be reverted/changed later. However that work is not settled yet, so we might want to land this anyway, as this code is not really ready for it yet.

As an example, we are pursuing this change: #25094 for that reason.

cc @nodejs/diagnostics

[mscdex]

ping @nodejs/tsc once more

[Trott]

There probably won't be a meeting this week, but I'm going to throw a tsc-agenda label on this to make sure it doesn't entirely fall off the TSC radar for a third time.

[Trott]

(Obviously, if resolution is achieved before the next TSC meeting, that's awesome and I'll be delighted to remove the label at that time.)

[mcollina]

Thanks for working on nextTick! I've got some questions.

I'm failing to understand why this changes improves performance, and if it may something related to our benchmarks.

Have you tried if moving just the emitInit call outside of the constructor generates the same result?
Have you verified that is using the same object for both emitInit and queue.push() is what is actually creating the performance improvements?

@mscdex have you experiences this improves things in a more realistic scenario including I/O?

Also cc @bmeurer who might provide some insights.

[mscdex]

Have you tried if moving just the emitInit call outside of the constructor generates the same result?
Have you verified that is using the same object for both emitInit and queue.push() is what is actually creating the performance improvements?

@mcollina I honestly don't remember now, I tried a lot of variations though at the time, and this was the only one that resulted in a positive improvement with no regressions.

[bmeurer]

The change looks reasonable to me (JavaScript wise), but I'm really not a good candidate to review this, since this is not my area of expertise.

[mcollina]

@bmeurer have you got a clue on why this is faster than the current one?

[bmeurer]

@mcollina Nope, sorry.

[apapirovski]

have you got a clue on why this is faster than the current one?

As far as I can tell, this should be mostly related to using symbols which are in my experience slower for both getting and setting properties (and for your version the fact that we use an if condition rather than just running the emitInit function). That said, happy to be corrected.

[BridgeAR]

Ping @mscdex
Please check #25461 (comment)

[mscdex]

I've made different changes now to avoid the issues with domain. The new benchmark results are:

                                               confidence improvement accuracy (*)    (**)   (***)
 process/next-tick-breadth-args.js n=10000000        ***     17.11 %       ±2.80%  ±3.74%  ±4.89%
 process/next-tick-breadth.js n=10000000             ***     40.88 %       ±2.72%  ±3.62%  ±4.71%
 process/next-tick-depth-args.js n=7000000           ***     21.87 %       ±2.18%  ±2.92%  ±3.82%
 process/next-tick-depth.js n=7000000                ***     23.58 %       ±7.60% ±10.12% ±13.17%
 process/next-tick-exec-args.js n=4000000            ***     39.07 %       ±1.88%  ±2.51%  ±3.28%
 process/next-tick-exec.js n=4000000                 ***     44.92 %       ±1.67%  ±2.23%  ±2.91%

[mscdex]

/cc @nodejs/collaborators

[mcollina]

@mscdex does it still fail the test in #25461 (comment)? Maybe we should add it to our suite.

[mscdex]

@mcollina It should not fail it because the same object is being used now. These changes are now more or less inlining the previous custom TickObject class constructor code.

[mcollina]

Would you mind adding that test to this PR? Code LGTM.

[mscdex]

@mcollina Honestly I think that's probably best left to a separate issue/PR about whether we should (explicitly) support modifying behavior like that from an async hook callback.

[mcollina]

LGTM

[benjamingr]

@hashseed @bmeurer why is this still faster? I thought this optimization of specializing the argument length explicitly in the code is no longer required?

[psmarshall]

Not sure - how much of the improvement is accounted for by this alone (and not the other part of this CL)?

Glancing at e.g. next-tick-depth-args, it doesn't look like the arguments to the callbacks are ever used - maybe we optimize something there. We don't do analysis like that for spread calls

[benjamingr]

@psmarshall the reason I was concerned is that we removed this optimization from certain parts of the code before.

[psmarshall]

I think it's possible to construct a microbenchmark where one or the other is faster - I don't think you could measure the difference on a larger application that does a lot of work between ticks. With that in mind my preference is for the spread-call version but I also don't really have the time to do a detailed analysis of what's going on in this specific case so I'm fine either way.