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

test, benchmark: create shared runBenchmark func #15004

Closed
wants to merge 6 commits into from

Conversation

maclover7
Copy link
Contributor

@maclover7 maclover7 commented Aug 24, 2017

Created from discussion starting at #14951 (comment). This is a proof of concept PR, and the exact implementation details can be tweaked, but I think this is generally what the API should look like. A few open points are below.

Needed for merge: all resolved

  • ESLint is raising with Mandatory module "common" must be loaded required-modules right now -- should files matching test-benchmark-*.jsneed to require common anymore? resolved

Can probably be handled after merge:

  • Does this new helper method need to be documented in test/common/README.md?
  • To a novice, it seems like n=1 is being everywhere except a few places -- should this become an included-by-default argv option in the new run method?
  • exchange args array option for an object instead
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

test, benchmark

@nodejs-github-bot nodejs-github-bot added the test Issues and PRs related to the tests. label Aug 24, 2017
@benjamingr
Copy link
Member

Can we see a run of the results before and after?

@maclover7
Copy link
Contributor Author

Can we see a run of the results before and after?

Not sure what you mean -- this PR doesn't affect the output of the benchmarks themselves, it just refactors the way they are run 😬

@benjamingr
Copy link
Member

Not sure what you mean -- this PR doesn't affect the output of the benchmarks themselves, it just refactors the way they are run 😬

Precisely, which is why I'd expect a benchmark before and after to return the same results and it would be a good sanity check that we did not change anything in the measuring code (in how the JIT looks at the code for example).

@mscdex mscdex added the benchmark Issues and PRs related to the benchmark subsystem. label Aug 24, 2017
@@ -0,0 +1,28 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

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

I believe this will need a /* eslint-disable required-modules */ at the top to pass linting.
Please run make lint to make sure :-)

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

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

Minor nit but I like it! Thank you for this.

@joyeecheung
Copy link
Member

@maclover7 I think you can verify this PR does not change how the benchmarks are tested by running something like:

for test in test/**/test-benchmark-*.js; do ./node $test; done

@joyeecheung
Copy link
Member

Also:

ESLint is raising with Mandatory module "common" must be loaded required-modules right now -- should files matching test-benchmark-*.jsneed to require common anymore?

Yes, we need to require('../common') to make sure no global variables are leaked during the test, .etc

Does this new helper method need to be documented in test/common/README.md?

That would be great but I would not think this is a blocker for this PR.

@maclover7
Copy link
Contributor Author

Here are two diffs of benchmark runs (thank you for the helpful bash script @joyeecheung!!) 1, 2. It does seem like the numbers vary a little bit even between runs on the same git branches, but I'm not sure if that's due to the changes here.

@Trott
Copy link
Member

Trott commented Aug 24, 2017

Totally minor nit that can be ignored if you want: I'd prefer benchmark as the name for the module rather than benchmarks.

The reason is that if everything is a singular noun, you never have to think about "Hmmm, is the name of the module benchmark or benchmarks? Let me go look." It's always going to be benchmark with no thinking necessary.

Of course, that ship has sailed already because I neglected to say something about the fixtures module. (A PR that changes it to fixture would be fine with me, but others might reject it as pointless churn.)

@joyeecheung
Copy link
Member

@maclover7
Copy link
Contributor Author

Totally minor nit that can be ignored if you want: I'd prefer benchmark as the name for the module rather than benchmarks.

@Trott while reading your great comment I actually came up with a different reason for renaming to benchmark -- the function exported is called runBenchmark, not runBenchmarks 🙃

Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

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

I like this approach a lot. LGTM

@BridgeAR
Copy link
Member

Just one suggestion: I think it makes sense to move the tests into one file as it is only very little code now.

@Trott
Copy link
Member

Trott commented Aug 25, 2017

Just one suggestion: I think it makes sense to move the tests into one file as it is only very little code now.

@BridgeAR Logically, that makes sense, but practically, that will likely result in a test that times out a lot on CI. These tests individually can take several seconds to run each. I would keep them separate.

@joyeecheung
Copy link
Member

Previous CI is incomplete. New CI: https://ci.nodejs.org/job/node-test-pull-request/9866/

@jasnell
Copy link
Member

jasnell commented Aug 29, 2017

I'd like to get signoff from @Trott before this lands.

@Trott
Copy link
Member

Trott commented Sep 1, 2017

I'd like to get signoff from @Trott before this lands.

LGTM

@Trott
Copy link
Member

Trott commented Sep 1, 2017

Oh, wait, I take it back! It needs a change.

Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

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

Code LGTM. The new benchmark module needs documentation. Can you at least minimally stub something out in test/common/README.md? There are already examples there that you can use as a model.

@maclover7
Copy link
Contributor Author

@Trott updated

@refack
Copy link
Contributor

refack commented Sep 1, 2017

Sorry to come in late, so @maclover7 take this as a non blocking request/question.
Why not have this as a method on common so you could do

const { runBenchmark } = require('./common');

Also I think a more appropriate name would be testBenchmark since the main motivation is to sanity test the benchmarks code, and we ignore the actual results.

@refack
Copy link
Contributor

refack commented Sep 2, 2017

Also folding the code into index.js will allow the use of a future patched fork as discussed in #14845

@maclover7
Copy link
Contributor Author

@refack no problem :)

Why not have this as a method on common

I think the original idea was that common was only for helper functions that could be used throughout the test suite, and since this function is benchmark specific, it seemed okay to create a separate module for it. (see also discussion beginning at #14951 (comment))

Also folding the code into index.js will allow the use of a future patched fork as discussed in

If I'm reading that PR right, I don't think the two should conflict? Whatever is wanted for process.env is passed as an object, so theoretically that could be anything. Either way, the specifics of the API can always be changed in a later PR, this one is just meant to be a first step :)

@Trott
Copy link
Member

Trott commented Sep 2, 2017

I'm definitely -1 on importing common via the smaller module and relaxing the lint rule. Importing common should be explicit in the test. @refack Can you clarify what problem your trying to solve with the suggestion?

@refack
Copy link
Contributor

refack commented Sep 2, 2017

[again comments are non-blocking]
This seems fragile (lint-able, but surprising), and requires understanding of the ../common mechanism.

require('../common');

const runBenchmark = require('../common/benchmark');

and folding the module in would allow us to do:

const { runBenchmark } = require('./common');

instead.

But explicitivity is a strong argument, and the lint rule will protect from forgetting to require('../common');

@Trott
Copy link
Member

Trott commented Sep 2, 2017

Ah, I see! Yeah, maybe the thing to do eventually is create a node_modules directory and put common inside it along side the other modules rather than having it look like a parent module. We'd want to enable linting for that node_modules directory unlike all the others. And having it there without a package.json might be confusing.
¯\(ツ)/¯ Maybe publish the modules to npm eventually. :-D

@refack refack self-assigned this Sep 2, 2017
@refack
Copy link
Contributor

refack commented Sep 2, 2017

@Trott
Copy link
Member

Trott commented Sep 4, 2017

This should be land-able but CI has been Not Fun the last few days. Hopefully that can get straightened out Tuesday if not sooner, but in the meantime, @maclover7, would you mind rebasing to get rid of the conflict?

@maclover7
Copy link
Contributor Author

maclover7 commented Sep 8, 2017

@Trott sorry for delay, rebased. read to land?

@BridgeAR
Copy link
Member

BridgeAR commented Sep 9, 2017

@refack
Copy link
Contributor

refack commented Sep 11, 2017

Landed in 640b206
D.R.Y. FTW!

@refack refack closed this Sep 11, 2017
refack pushed a commit that referenced this pull request Sep 11, 2017
Mostly shared/duplicated logic between all benchmark test files, so
creating a new common module to store it.

PR-URL: #15004
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@maclover7 maclover7 deleted the jm-common-benchmark branch September 11, 2017 21:37
addaleax pushed a commit to addaleax/node that referenced this pull request Sep 13, 2017
Mostly shared/duplicated logic between all benchmark test files, so
creating a new common module to store it.

PR-URL: nodejs#15004
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
jasnell pushed a commit that referenced this pull request Sep 20, 2017
Mostly shared/duplicated logic between all benchmark test files, so
creating a new common module to store it.

PR-URL: #15004
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@MylesBorins
Copy link
Contributor

This does not land cleanly in LTS. Please feel free to manually backport by following the guide. Please also feel free to replace do-not-land if it is being backported

@Trott
Copy link
Member

Trott commented Oct 18, 2017

I think it's important that this one be backported. I'm going to change the label to backport-requested. Hopefully @maclover7 can do it, but if not, I or someone else can step in to do it.

@Trott
Copy link
Member

Trott commented Oct 18, 2017

Oh, wait, it landed on 8.x already. The backport would be for 6.x. I'd still prefer to see it than not, but I don't feel so strongly that I'm going to change the label. :-D

@refack refack removed their assignment Oct 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
benchmark Issues and PRs related to the benchmark subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.