You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 28, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 28, 2020. It is now read-only.
Setup bluebird and/or wikipedia benchmarks for promise performance #188
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).
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.
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?
@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 Makes sense. I've created versions of these benchmarks, see https://github.com/v8/promise-performance-tests, which we use for V8 internally to track Promise and async/await performance. Shouldn't be hard to setup on Node infrastructure as well (and run with async_hook on and off).
Activity
bmeurer commentedon Jan 15, 2018
Also see the first item on the list for nodejs/diagnostics#124.
Initial import of the benchmark and the results.
bmeurer commentedon Jan 16, 2018
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 emptyinithook.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_hookscan be shipped liked this.AndreasMadsen commentedon Jan 16, 2018
@bmeurer By bluebird, do you mean with petkaantonov/bluebird#1472 applied?
bmeurer commentedon Jan 16, 2018
No it's the bluebird benchmarks running with native promises.
alexkozy commentedon Jan 17, 2018
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 commentedon Jan 17, 2018
@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 commentedon Jan 31, 2018
Discussed, last meeting, nothing for TSC to decide at this point. Let async hooks team address, removing tag for now.
ofrobots commentedon Jan 31, 2018
Seems like @nodejs/async_hooks hasn't been mentioned here yet. Doing so.
Trott commentedon Feb 13, 2018
Seems like the
tsc-agendalabel should be removed? If I'm wrong about that, by all means, add it again.mhdawson commentedon Feb 15, 2018
@Trott thanks, I had removed manually from the last agenda, but forgot to remove the tag.
mhdawson commentedon Apr 2, 2018
@bmeurer since we have no other promise centric benchmarks I'm wondering if running these nightly would be better than nothing?
bmeurer commentedon Apr 3, 2018
@mhdawson Makes sense. I've created versions of these benchmarks, see https://github.com/v8/promise-performance-tests, which we use for V8 internally to track
Promiseandasync/awaitperformance. Shouldn't be hard to setup on Node infrastructure as well (and run withasync_hookon and off).