Uh oh!
There was an error while loading. Please reload this page.
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.
apapirovski
commented
May 1, 2018
mscdex
commented
May 1, 2018
Can you share benchmark results? |
apapirovski
commented
May 1, 2018
@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 |
| 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.
apapirovski
commented
May 2, 2018
CI after the change proposed by @bnoordhuis: https://ci.nodejs.org/job/node-test-pull-request/14621/ |
apapirovski
commented
May 3, 2018
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