feat(chain): schedule handlers to the next tick

[hekike]

Schedule handlers to nextTick for cleaner Flamegraphs.
Shouldn't have an effect on performance:

? Do you want to track progress? No
? Do you want to compare HEAD with the stable release (7.2.0)? Yes
? Do you want to run all benchmark tests? Yes
? How many connections do you need? 100
? How many pipelining do you need? 10
? How long does it take? 30
---- response-json ----
⠋ Started head/response-json
✔ Results saved for head/response-json
✔ Results saved for stable/response-json
response-json throughput:
{
    "significant": "",
    "equal": true
}

---- response-text ----
✔ Results saved for head/response-text
✔ Results saved for stable/response-text
response-text throughput:
{
    "significant": "",
    "equal": true
}

---- router-heavy ----
✔ Results saved for head/router-heavy
✔ Results saved for stable/router-heavy
router-heavy throughput:
{
    "significant": "***",
    "equal": true
}

---- middleware ----
✔ Results saved for head/middleware
✔ Results saved for stable/middleware
middleware throughput:
{
    "significant": "",
    "equal": true
}

[kenashcraft]

Have you run the benchmarks with this PR? Consider this implementation instead:
process.nextTick(handler, req, res, next);
Looking at the implementation of nextTick with Julien, it isn't clear which would be faster.

[hekike]

yes I run, looks like no effect

[hekike]

The goal would be cleaner flamegraphs not faster execution.

[DonutEspresso]

LGTM! Wondering if this should be an option? Otherwise it's a breaking change, I think.

[DonutEspresso]

Is this enough to reset the FG stack? Or do we need setImmediate?

[hekike]

cc @misterdjules

[misterdjules]

What do we mean by "FG stack"? If the question is whether the handler call's stack frame would not have the previous handler as a parent stack frame, the answer is yes, it would not have the previous handler as a parent stack frame.

[misterdjules]

Ah Peter clarified that FG is for Flame Graphs :)

[hekike]

@DonutEspresso why do you think it's a breaking change? It doesn't affect any of the public APIs or execution order.

[DonutEspresso]

If it's nextTick it's probably not breaking - if it's setImmediate then I'm thinking in a worst case scenario this could cause the queueing behavior to change, e.g., the number of inflight requests may increase and latency gets amortized across the requests in the queue.