New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf: eager poll async ops in Isolate #3046
Conversation
993c0a5
to
58cb188
Compare
506b45f
to
30d8a05
Compare
@ry I'm very close with this PR, I'm still having some trouble with
EDIT: Got it figured out - need to |
Latest benchmarks from my machine: Threadpool runtime
Deno v0.20.0
Current thread runtime
Deno v0.20.0
|
Update: still having some troubles with |
417aeee
to
8ab0b52
Compare
Two things left to do:
Getting close 💪 |
@ry ready for review 🎉 also CC @piscisaureus |
}); | ||
tokio_util::run(bundle_future); | ||
}); | ||
tokio_util::run(main_future); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really understand this change... it seems like it should be functionally equivalent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it looks like it, but if we don't poll isolate then task is not properly set up and ts_compiler
panics.
Looks good - I'm in favor of landing this. Nice work! I look forward to seeing the benchmarks page updated. I want to give @piscisaureus a chance to review since this is very sensitive code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving because I want to see the benchmark results.
If it sticks, I hope we can make the integration a bit more streamlined and bring back some of the fairness of the old scheduler (e.g. after 20 eager poll short-circuits, revert back to deferred polling).
Very nice work @bartlomieju! This PR has proven significant perf gains in the http server benchmark and throughput benchmark: However it has increased tail latency. @bartlomieju's subsequent #3128 has mediated it to reasonable levels: It's worth noting that our benchmark page is generated inside Github Actions, which are perhaps not the best servers to undertake CPU heavy measurements. On the benchmarks page, deno_tcp is shown as performing better than node_tcp. On my own machine, when I benchmark them, node_tcp is still significantly better: deno_tcp:
node_tcp:
So there is still work to do. We will be able to upgrade to Tokio's new scheduler in the coming weeks, which should shed some light on how much of this overhead is due to our dependencies. |
Revamp of #2779 with new dispatcher infra.
I get ridiculous result on my machine...
this PR debug
master debug
this PR release
master release
That's ~90% increase for debug and ~20% for release. You can see that latency got worse, but that's promising results.
CC @ry