-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Conversation
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 😬 |
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). |
test/common/benchmarks.js
Outdated
@@ -0,0 +1,28 @@ | |||
'use strict'; |
There was a problem hiding this comment.
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 :-)
There was a problem hiding this 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.
@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 |
Also:
Yes, we need to
That would be great but I would not think this is a blocker for this PR. |
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. |
Totally minor nit that can be ignored if you want: I'd prefer The reason is that if everything is a singular noun, you never have to think about "Hmmm, is the name of the module Of course, that ship has sailed already because I neglected to say something about the |
@Trott while reading your great comment I actually came up with a different reason for renaming to |
There was a problem hiding this 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
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. |
Previous CI is incomplete. New CI: https://ci.nodejs.org/job/node-test-pull-request/9866/ |
I'd like to get signoff from @Trott before this lands. |
LGTM |
Oh, wait, I take it back! It needs a change. |
There was a problem hiding this 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.
6c8bccd
to
7c06659
Compare
@Trott updated |
7c06659
to
3261f6a
Compare
Sorry to come in late, so @maclover7 take this as a non blocking request/question. const { runBenchmark } = require('./common'); Also I think a more appropriate name would be |
Also folding the code into |
@refack no problem :)
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))
If I'm reading that PR right, I don't think the two should conflict? Whatever is wanted for |
I'm definitely -1 on importing |
[again comments are non-blocking] 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 |
Ah, I see! Yeah, maybe the thing to do eventually is create a |
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? |
Mostly shared/duplicated logic between all benchmark test files, so creating a new common module to store it.
4cfc681
to
b3f4c41
Compare
@Trott sorry for delay, rebased. read to land? |
Landed in 640b206 |
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>
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>
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>
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 |
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. |
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 |
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
Mandatory module "common" must be loaded required-modules
right now -- should files matchingtest-benchmark-*.js
need to requirecommon
anymore? resolvedCan probably be handled after merge:
test/common/README.md
?n=1
is being everywhere except a few places -- should this become an included-by-default argv option in the new run method?args
array option for an object insteadChecklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test, benchmark