events: optimize condition for optimal scenario#20452
events: optimize condition for optimal scenario#20452apapirovski wants to merge 2 commits intonodejs:masterfrom
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.
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.
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 <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>
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>
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>
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