-
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: optimize condition for optimal scenario #20452
events: optimize condition for optimal scenario #20452
Conversation
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.
Can you share benchmark results? |
@mscdex I'm not claiming it's huge or anything but it's like 1.5-2% with 100 runs.
IMO it's a pretty sensible change. The code inside the |
lib/events.js
Outdated
process.emitWarning(w); | ||
} | ||
m = $getMaxListeners(target); | ||
if (m && m > 0 && existing.length > m && !existing.warned) { |
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.
If you have time and inclination to test: does reducing m && m > 0
to m > 0
make a difference?
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.
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.
CI after the change proposed by @bnoordhuis: https://ci.nodejs.org/job/node-test-pull-request/14621/ |
Landed in fe87945 |
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 <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
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 <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
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 <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]>
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), orvcbuild test
(Windows) passes