-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
events: support abortsignal in ee.on #35877
Conversation
Last benchmark run on my computer. I believe this regression indicates we should not merge this before fixing it even if we decide this API is good and we like it:
|
2e57831
to
77eefd3
Compare
77eefd3
to
866e7af
Compare
The performance regressions still looks pretty bad @addaleax @jasnell :
(from our CI https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/674/console ) I am kind of confused by this and will investigate but any help/idea welcome |
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.
It’s not really obvious to me what’s going on performance-wise here either, sorry :/
lib/events.js
Outdated
if (options !== undefined) { | ||
const signal = options ? options.signal : undefined; | ||
validateAbortSignal(signal, 'options.signal'); | ||
if (signal.aborted) { |
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.
This would throw if signal === undefined
, btw, and it doesn’t look like that would be intentional
The reason of the slowdown is that you are adding an additional parameter... this adds an additional frame if there is an arguments length mismatch. An API with fixed arguments is around 10% faster than one with fixed arguments.: normally this would not matter much but The good news is that the V8 is already working on the problem: https://bugs.chromium.org/p/v8/issues/detail?id=10201#c94. On the API side, I would focus more on supporting this in other places: |
@mcollina thanks that makes perfect sense. |
I will close this in the meantime and suggest we revisit this once V8 has made optimizing this possible. I don't think we can justify the perf regression at this point and the promise returning variants already support AbortSignal. That said if others feel strongly feel free to take the code here (with or without attribution) and try to gain consensus for it (I'd be -0). Thanks for the help Anna/Matteo! |
Also, I'll see about I'll try to make a small change (like only readFile) and iterate from there. |
I do have that in a branch but I haven't worked on it in a few months so it will need rebasing. I'd appreciate if you could take a look at the approach taken in #34080 and let me know if that seems reasonable enough to make a real pull request out of. If so, then I will rebase it and remove the draft status, and follow up with (I don't think I'd be able to get around to it this week or next week, but hopefully the week after.) |
Sadly I did not get around to it last week and it looks like I won't be able to until January. Sorry for mis-estimating! If someone else would like to pick it up sooner, I'll be happy to do whatever is necessary to hand it off. |
v8 has now fixed the "adding an undeclared argument introduces a 10% overhead" problem, so this can be revisited. |
@erichocean waiting for Node to update its v8 version first :) |
Going to see what performance looks like now. Edit: Ignore the merge commit this is just here to make it easier to run benchmarks, https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1088/ |
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'm -1 on this. I don't think there is a good way to do it without decreasing perf. I don't see how this would benefit our APIs.
I think we can agree that if there is a significant perf regression this shouldn't land. |
Benchmarks locally still show a 4% (significant) regression - let's try again in a year :) |
An attempt to support passing a signal to
EventEmitter
's once in order to unsubscribe.This is useful for ergonomically unsubscribing from multiple events at once.
This is very much WIP and should not be merged. It currently introduces a ±12% performance regression in the add/remove listeners benchmarks.
I am interested mostly in:
AbortSignal
s inaddEventListener
s options to unsubscribe from events? whatwg/dom#911 ) is a good idea.removeListener
andaddListener
on the emitter when a signal is passed for the first time maybe?)cc @nodejs/events @jasnell
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes