Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

test: add test for child_process benchmark #12326

Closed
wants to merge 1 commit into from

Conversation

joyeecheung
Copy link
Member

Refs: #12068

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

test, benchmark

@nodejs-github-bot nodejs-github-bot added benchmark Issues and PRs related to the benchmark subsystem. child_process Issues and PRs related to the child_process subsystem. test Issues and PRs related to the tests. labels Apr 11, 2017
@joyeecheung
Copy link
Member Author

@@ -1,12 +1,12 @@
'use strict';
var common = require('../common.js');
var bench = common.createBenchmark(main, {
thousands: [1]
len: [1000]
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure about this change. In the other benchmarks, len is a message length in bytes I think. Here, it is a number of iterations, so len is kind of misleading because it's not a length. We tend to use n for this sort of thing instead.

I'm not opposed to this, but would be curious what others thought. @nodejs/benchmarking @mscdex

Copy link
Member

Choose a reason for hiding this comment

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

Actually, I see that you already set n to 1 when you launch the benchmarks, so maybe this should just be n and that's that?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, we should be more consistent and use n where possible. There are some benchmarks like this and others that use thousands or millions though. I prefer to just use n, even if the values are large, for consistency.

Copy link
Member Author

@joyeecheung joyeecheung Apr 12, 2017

Choose a reason for hiding this comment

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

Yeah I think I renamed this to len because I mistook this one for another benchmark when editing :S..this should've been n, good catch!

@joyeecheung
Copy link
Member Author

Updated to use n in spawn-echo.js.

New CI: https://ci.nodejs.org/job/node-test-pull-request/7368/

@joyeecheung
Copy link
Member Author

I am going to land this in 24 hours if no one objects to the update :)

@joyeecheung
Copy link
Member Author

Landed in 3d7c82b, thanks!

joyeecheung added a commit that referenced this pull request Apr 19, 2017
PR-URL: #12326
Ref: #12068
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
@vsemozhetbyt
Copy link
Contributor

FWIW, sequential/test-benchmark-child-process hangs on some Windows CI.

@jasnell
Copy link
Member

jasnell commented Apr 19, 2017

Oh good, it's not just me. test-benchmark-child-process definitely appears to be somewhat flaky on Windows CI.

@Trott
Copy link
Member

Trott commented Apr 19, 2017

This landed despite the added test failing on the Windows CI run for this PR. :-(

Seems to run OK on all the CI Windows types except Windows 2016. Maybe yes.exe isn't installed there? @nodejs/build

@Trott
Copy link
Member

Trott commented Apr 19, 2017

Although I don't think it would hang if that's the case...it would exit with ENOENT, I think.

@joyeecheung
Copy link
Member Author

Oh no, sorry for the trouble, should've checked the new CI :(

evanlucas pushed a commit that referenced this pull request Apr 25, 2017
PR-URL: #12326
Ref: #12068
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
@evanlucas evanlucas mentioned this pull request May 1, 2017
evanlucas pushed a commit that referenced this pull request May 1, 2017
PR-URL: #12326
Ref: #12068
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
evanlucas pushed a commit that referenced this pull request May 2, 2017
PR-URL: #12326
Ref: #12068
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
@gibfahn
Copy link
Member

gibfahn commented May 16, 2017

Opting to let this bake a while longer. This should land with #12518 (and possibly #12561)

@gibfahn gibfahn added baking-for-lts PRs that need to wait before landing in a LTS release. lts-watch-v6.x labels May 16, 2017
@MylesBorins MylesBorins removed the baking-for-lts PRs that need to wait before landing in a LTS release. label Aug 17, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
benchmark Issues and PRs related to the benchmark subsystem. child_process Issues and PRs related to the child_process subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants