Skip to content
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

lib: expose FixedQueue internally and fix nextTick bug #20468

Closed
wants to merge 2 commits into from

Conversation

apapirovski
Copy link
Member

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
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

@apapirovski apapirovski added process Issues and PRs related to the process subsystem. lib / src Issues and PRs related to general changes in the lib or src directory. labels May 2, 2018
@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. process Issues and PRs related to the process subsystem. labels May 2, 2018
@apapirovski
Copy link
Member Author

@apapirovski apapirovski removed the build Issues and PRs related to build files or the CI. label May 2, 2018
@mscdex
Copy link
Contributor

mscdex commented May 2, 2018

Any change in benchmark results after these changes?

@apapirovski
Copy link
Member Author

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

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.
@apapirovski
Copy link
Member Author

apapirovski commented May 3, 2018

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

@apapirovski apapirovski added the performance Issues and PRs related to the performance of Node.js. label May 3, 2018
@@ -222,6 +112,8 @@ function setupNextTick() {
args[i - 1] = arguments[i];
}

push(new TickObject(callback, args, getDefaultTriggerAsyncId()));
if (queue.isEmpty())
tickInfo[kHasScheduled] = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice find!

Copy link
Member

@benjamingr benjamingr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on the fix and also extracting FixedQueue though I'm not sure why it's in the same PR. Changes LGTM.

@apapirovski
Copy link
Member Author

+1 on the fix and also extracting FixedQueue though I'm not sure why it's in the same PR. Changes LGTM.

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?

@apapirovski apapirovski added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 4, 2018
Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@apapirovski
Copy link
Member Author

Landed in 9a3ae2f

@apapirovski apapirovski closed this May 6, 2018
@apapirovski apapirovski deleted the patch-fixed-queue branch May 6, 2018 05:22
apapirovski added a commit that referenced this pull request May 6, 2018
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 <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 8, 2018
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 <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
@MylesBorins MylesBorins mentioned this pull request May 8, 2018
MylesBorins pushed a commit that referenced this pull request May 8, 2018
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 <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 9, 2018
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 <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. lib / src Issues and PRs related to general changes in the lib or src directory. performance Issues and PRs related to the performance of Node.js. process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants