| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Any change in benchmark results after these changes? |
Sorry, something went wrong.
|
@mscdex I don't have time to run them locally until tomorrow but quick runs indicated +-2% change. I'm waiting on my two earlier PRs that fix nextTick benchmarks to land and then will run it on the CI. |
Sorry, something went wrong.
A bug was introduced together with the FixedQueue implementation for process.nextTick which meant that the queue wouldn't necessarily fully clear on each run through. Fix it and abstract the data structure into an internal module that can later be used elsewhere.
Sorry, something went wrong.
|
@nodejs/process @nodejs/performance I would appreciate some reviews on this. This fixes a bug in nextTick and with the recent changes also significantly improves its performance in most usage: confidence improvement accuracy (*) (**) (***) process/next-tick-breadth-args.js n=4000000 *** 13.19 % ±1.91% ±2.52% ±3.23% process/next-tick-breadth.js n=4000000 *** 36.53 % ±3.42% ±4.52% ±5.82% process/next-tick-depth-args.js n=12000000 *** 3.95 % ±1.44% ±1.90% ±2.43% process/next-tick-depth.js n=12000000 0.44 % ±1.71% ±2.25% ±2.89% process/next-tick-exec-args.js n=5000000 *** 15.48 % ±2.26% ±2.98% ±3.83% process/next-tick-exec.js n=5000000 *** 22.22 % ±2.49% ±3.28% ±4.22% confidence improvement accuracy (*) (**) (***) streams/creation.js kind='duplex' n=50000000 0.47 % ±1.12% ±1.48% ±1.90% streams/creation.js kind='readable' n=50000000 1.17 % ±1.51% ±2.00% ±2.57% streams/creation.js kind='transform' n=50000000 -0.33 % ±1.05% ±1.39% ±1.79% streams/creation.js kind='writable' n=50000000 0.49 % ±1.49% ±1.97% ±2.53% streams/pipe.js n=5000000 ** 4.26 % ±2.68% ±3.53% ±4.53% streams/pipe-object-mode.js n=5000000 1.56 % ±2.35% ±3.10% ±3.99% streams/readable-bigread.js n=1000 0.14 % ±1.65% ±2.17% ±2.79% streams/readable-bigunevenread.js n=1000 0.54 % ±1.34% ±1.77% ±2.27% streams/readable-boundaryread.js type='buffer' n=2000 *** -2.50 % ±0.87% ±1.15% ±1.47% streams/readable-boundaryread.js type='string' n=2000 -0.24 % ±0.89% ±1.18% ±1.51% streams/readable-readall.js n=5000 0.28 % ±1.31% ±1.73% ±2.22% streams/readable-unevenread.js n=1000 -0.58 % ±0.68% ±0.89% ±1.15% streams/writable-manywrites.js n=2000000 *** 6.63 % ±1.68% ±2.21% ±2.84% |
Sorry, something went wrong.
|
|
||
| push(new TickObject(callback, args, getDefaultTriggerAsyncId())); | ||
| if (queue.isEmpty()) | ||
| tickInfo[kHasScheduled] = 1; |
There was a problem hiding this comment.
Nice find!
Sorry, something went wrong.
There was a problem hiding this comment.
+1 on the fix and also extracting FixedQueue though I'm not sure why it's in the same PR. Changes LGTM.
Sorry, something went wrong.
I started by extracting it then found the bug. Since this adjusts the FixedQueue API a decent amount, it didn't feel like it was necessary to do them in two separate PRs. It also allows us to provide more robust tests for FixedQueue itself, not just for nextTick. @addaleax I know you wrote the original documentation for this. Were the changes I made to account for the new behaviour clear enough? |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
A bug was introduced together with the FixedQueue implementation for process.nextTick which meant that the queue wouldn't necessarily fully clear on each run through. Fix it and abstract the data structure into an internal module that can later be used elsewhere. PR-URL: #20468 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
A bug was introduced together with the FixedQueue implementation for process.nextTick which meant that the queue wouldn't necessarily fully clear on each run through. Fix it and abstract the data structure into an internal module that can later be used elsewhere. PR-URL: #20468 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
A bug was introduced together with the FixedQueue implementation for process.nextTick which meant that the queue wouldn't necessarily fully clear on each run through. Fix it and abstract the data structure into an internal module that can later be used elsewhere. PR-URL: #20468 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
A bug was introduced together with the FixedQueue implementation for process.nextTick which meant that the queue wouldn't necessarily fully clear on each run through. Fix it and abstract the data structure into an internal module that can later be used elsewhere. PR-URL: #20468 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
| Back | FazBrowse Home | New Git URL |
A bug was introduced together with the FixedQueue implementation for process.nextTick which meant that the queue wouldn't necessarily fully clear on each run through. Fix it and abstract the data structure into an internal module that can later be re-used elsewhere.
I'm currently working on tests for the FixedQueue itself. Those should come in the next 24 hours.
The abstraction is in preparation for another PR that uses the FixedQueue in another module. (That said, the fact that we'll be able to properly test it outside of nextTick is also a nice side-effect.)
Checklist