Setup bluebird and/or wikipedia benchmarks for promise performance

[bmeurer]

Specifically we're interested in the difference between regular runs with these workloads and runs where we have async_hooks enabled (see #181 for background).

[bmeurer]

Also see the first item on the list for nodejs/diagnostics#124.

[bmeurer]

Ok, I managed to run the aforementioned benchmarks today with and without async_hooks, and the results show a significant slow-down, even with just an empty init hook.

The full results and benchmarks are available at https://github.com/bmeurer/async-hooks-performance-impact. Not sure it makes sense to include these benchmarks as part of the regular nightly runs at this point. It seems that we might first need to come to an agreement whether we think that async_hooks can be shipped liked this.

[AndreasMadsen]

@bmeurer By bluebird, do you mean with petkaantonov/bluebird#1472 applied?

[bmeurer]

No it's the bluebird benchmarks running with native promises.

[alexkozy]

It looks like to implement async_hooks for promises V8 enters C++ code and then go back into JavaScript land to call actual callback. Should we somehow migrate promise hooks from C++ builtin to TF builtin to get a performance boost?

And probably it is not best place for this question but what is main use case for async_hooks? Is it for some kind of async context tracking?

[bmeurer]

@gsathya already suggested to move the promise hooks to JS and eventually spec them. This would help to reduce the C++ overhead, but so far I don't think that's the only/main bottleneck.

[mhdawson]

Discussed, last meeting, nothing for TSC to decide at this point. Let async hooks team address, removing tag for now.

[ofrobots]

Seems like @nodejs/async_hooks hasn't been mentioned here yet. Doing so.

[Trott]

Seems like the tsc-agenda label should be removed? If I'm wrong about that, by all means, add it again.

[mhdawson]

@Trott thanks, I had removed manually from the last agenda, but forgot to remove the tag.