Skip to content

events: optimize condition for optimal scenario - #20452

Closed
apapirovski wants to merge 2 commits into
nodejs:masterfrom
apapirovski:patch-events-max-listeners-check
Closed

events: optimize condition for optimal scenario#20452
apapirovski wants to merge 2 commits into
nodejs:masterfrom
apapirovski:patch-events-max-listeners-check

Conversation

@apapirovski

Copy link
Copy Markdown
Contributor

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.
@apapirovskiapapirovski added the events Issues and PRs related to the events subsystem / EventEmitter. label May 1, 2018
@apapirovski

Copy link
Copy Markdown
ContributorAuthor

@mscdex

Copy link
Copy Markdown
Contributor

Can you share benchmark results?

@apapirovski

Copy link
Copy Markdown
ContributorAuthor

@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.

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

Copy link
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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

@apapirovskiapapirovski 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
Copy Markdown
ContributorAuthor

Landed in fe87945

@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>
@MylesBorinsMylesBorins 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 freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author readyPRs that have at least one approval, no pending requests for changes, and a CI started.eventsIssues and PRs related to the events subsystem / EventEmitter.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@apapirovski@mscdex@bnoordhuis@jasnell@lpinca@cjihrig@tniessen@BridgeAR@trivikr