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

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

ping?

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

ping @nodejs/tsc once more

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.

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

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.

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.

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

@mcollina Nope, sorry.

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.

Ping @mscdex
Please check #25461 (comment)

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%

/cc @nodejs/collaborators

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

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

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

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