Skip to content
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: optimize condition for optimal scenario #20452

Closed

Conversation

apapirovski
Copy link
Member

Instead of always checking whether we've already warned about a possible EventEmitter memory leak, first run the rest of the code as accessing custom properties on an Array is decently slow.

I believe it makes more sense to optimize for well written user-code than code that is already attaching too many listeners and getting this warning, without having set a higher number of maxListeners.

I've also adjusted the benchmark to be a bit more representative as there's too much noise with the current iteration count.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

Instead of always checking whether we've already warned about a
possible EventEmitter memory leak, first run the rest of the
code as accessing random properties on an Array is expensive.
@apapirovski apapirovski added the events Issues and PRs related to the events subsystem / EventEmitter. label May 1, 2018
@apapirovski
Copy link
Member Author

@mscdex
Copy link
Contributor

mscdex commented May 1, 2018

Can you share benchmark results?

@apapirovski
Copy link
Member Author

@mscdex I'm not claiming it's huge or anything but it's like 1.5-2% with 100 runs.

                                  confidence improvement accuracy (*)   (**)  (***)
 events/ee-add-remove.js n=250000        ***      2.01 %       ±0.74% ±0.97% ±1.25%

IMO it's a pretty sensible change. The code inside the if runs anyway unless we've already emitted that warning. This way we can bail out one check earlier in all cases but the one where someone actually triggers the warning.

lib/events.js Outdated
process.emitWarning(w);
}
m = $getMaxListeners(target);
if (m && m > 0 && existing.length > m && !existing.warned) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have time and inclination to test: does reducing m && m > 0 to m > 0 make a difference?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it makes a difference yet but it seems a harmless change and simplifies the conditional further. I don't see why we shouldn't do it.

@apapirovski
Copy link
Member Author

CI after the change proposed by @bnoordhuis: https://ci.nodejs.org/job/node-test-pull-request/14621/

@apapirovski apapirovski added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 2, 2018
@apapirovski
Copy link
Member Author

Landed in fe87945

@apapirovski apapirovski closed this May 3, 2018
@apapirovski apapirovski deleted the patch-events-max-listeners-check branch May 3, 2018 12:45
apapirovski added a commit that referenced this pull request May 3, 2018
Instead of always checking whether we've already warned about a
possible EventEmitter memory leak, first run the rest of the
code as accessing random properties on an Array is expensive.

In addition, remove an unnecessary truthy check.

PR-URL: #20452
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
MylesBorins pushed a commit that referenced this pull request May 4, 2018
Instead of always checking whether we've already warned about a
possible EventEmitter memory leak, first run the rest of the
code as accessing random properties on an Array is expensive.

In addition, remove an unnecessary truthy check.

PR-URL: #20452
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
@MylesBorins MylesBorins mentioned this pull request May 8, 2018
MylesBorins pushed a commit that referenced this pull request May 8, 2018
Instead of always checking whether we've already warned about a
possible EventEmitter memory leak, first run the rest of the
code as accessing random properties on an Array is expensive.

In addition, remove an unnecessary truthy check.

PR-URL: #20452
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. events Issues and PRs related to the events subsystem / EventEmitter.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants