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: only refresh tmpDir for tests that need it #1954

Closed
wants to merge 1 commit into from

Conversation

Trott
Copy link
Member

@Trott Trott commented Jun 12, 2015

Expose common.refreshTmpDir() and only call it
for tests that use common.tmpDir or common.PIPE.

A positive side effect is the removal of a code
smell where child processes were detected by the
presence of .send(). Now each process can decide
for itself if it needs to refresh tmpDir.

/cc @rvagg (who suggested this approach in comments on #1877)

@mscdex mscdex added the test Issues and PRs related to the tests. label Jun 12, 2015
@rvagg
Copy link
Member

rvagg commented Jun 12, 2015

for tests that use common.tmpDir or common.PIPE.

Note that common.PIPE isn't necessarily in the temporary directory - we set it to something completely different on all of the CI machines because of the character limit in path names for pipes and on Windows it's a named pipe so has nothing to do with the filesystem. So if you wanted to you could optimise even further! Up to you though.

I'd love to see some timing numbers for this, can you time a full test run with and without this change and post the results here?

try {
rimrafSync(exports.tmpDir);
} catch (e) {
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this usually goes on the same line } catch (e) { }, is the linter OK with that?

Copy link
Member Author

Choose a reason for hiding this comment

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

make jslint doesn't complain. There's one similar occurrence in the file (although it has a comment in the empty block so maybe that's different): https://github.com/nodejs/io.js/blob/a6b8ee19b85bbd798510191f0aee596f36b909d2/test/common.js#L159-L161

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm. I'd say the comment makes it a little bit different, but i'll leave it up to you if the linter is happy either way.

@Trott
Copy link
Member Author

Trott commented Jun 12, 2015

I'd love to see some timing numbers for this, can you time a full test run with and without this change and post the results here?

Do you mean something like time python tools/test.py --mode=release message parallel sequential -J a few times each with and without this optimization? Or is there a relatively easy way to get better numbers?

@brendanashworth
Copy link
Contributor

@Trott probably for this, I'd think time python tools/test.py --mode=release parallel would be best. (but Rod is the build master so he knows better)

@rvagg
Copy link
Member

rvagg commented Jun 13, 2015

yeah, just a time of this branch vs master would be interesting, doesn't need to be precise, just interesting to see what (if anything) this is buying us. Leave out parallel for now I think.

@jbergstroem
Copy link
Member

Might as well try both

@Trott
Copy link
Member Author

Trott commented Jun 13, 2015

Not seeing a dramatic difference running time python tools/test.py --mode=release message sequential but there is something (although this is n of 1 so it could just be random variation).

master:

real    0m41.301s
user    0m29.730s
sys 0m4.569s

Branch in this PR:

real    0m40.614s
user    0m29.308s
sys 0m4.375s

@rvagg
Copy link
Member

rvagg commented Jun 13, 2015

oh, that's disappointing! I'm supposed to send you Jenkins creds so when you get them you can run on the CI cluster and compare run times across platforms, if we get a big enough win on the ARM machines then this'd be worth it

@Trott
Copy link
Member Author

Trott commented Jun 13, 2015

On Jenkins, armv7-ubuntu-1404 takes 13 minutes with and without this change. No measurable change.

I suspect that will be the story across the board, despite my fervent hope that it shaves a few minutes of the Raspberry Pi test runs (which I guess we'll find out about in the next hour or so).

Jenkins runs against:

I'm still in favor of this change. It gets rid of the code smell where child processes were detected by the presence of .send(). I wasn't really comfortable with that one.

But I can see a counterargument that it introduces complexity compared to the previous "always refresh the tmpdir no matter what" approach.

@rvagg
Copy link
Member

rvagg commented Jun 13, 2015

armv7-ubuntu-1404 may actually be quicker at fs operations than some of the other slaves because they have local eMMC storage, not virtualized like most of the other machines and not an SD card like the pi's.

@Trott
Copy link
Member Author

Trott commented Jun 13, 2015

Ah, OK. I'll hold out hope a bit.

I should probably be comparing test run times and not the whole time listed which will include the build time. I'm unfamiliar with Jenkins and not seeing an easy way to get a total time spent running tests. The best I've found is comparing times for individual tests in the TAP Extended Test Results. If there's an obvious better place for me to look, please clue me in.

@rvagg
Copy link
Member

rvagg commented Jun 13, 2015

Yeah, this is a good point actually - some of the slave groups are backed by multiple machines and some of them use ccache so there's no guarantee you're going to get a similar build time! most of the standard linux slaves are backed by a single machine, all of the ARM except for the ubuntu1404 one are backed by multiples as is Windows. This might be a fruitless excercise UNLESS you push two branches that put a time in front of test.py execution so you get that on the output.

Expose `common.refreshTmpDir()` and only call it
for tests that use common.tmpDir or common.PIPE.

A positive side effect is the removal of a code
smell where child processes were detected by the
presence of `.send()`. Now each process can decide
for itself if it needs to refresh tmpDir.
@Trott
Copy link
Member Author

Trott commented Jun 13, 2015

I followed your (@rvagg) suggestion to put time in the Makefile to see what results we get with the tmpdir refresh happening for every test vs. happening only for the tests that need it. Obviously, all the platforms that don't have a time command (or didn't have it installed for whatever reason) failed. But of the ones that succeeded, here's how it ended up.

As you can see in the table below, elapsed execution is faster (with one exception), but not always by a whole lot. The largest savings is ubuntu1404-64 shaving off 42 seconds. I have no idea what's up with ubuntu1404-32 which took 7 seconds longer. In both cases, I don't know how much of the change is ordinary variability. But I think it's probably significant that 9 out of 10 builds were faster and the one that wasn't was only a little bit slower.

PlatformMaster RealPR RealMaster UserPR UserMaster SysPR Sys
freebsd101-32309.68308.58197.77197.3018.8018.32
freebsd101-64308.40308.06186.25185.2527.8228.04
osx1010302.72298.09176.84173.4034.6434.38
smartos14-327:32.77:16.23:24.13:21.02:05.42:03.5
smartos14-647:24.97:22.33:13.13:11.62:15.52:13.7
ubuntu1204-646:52.186:36.35265.79253.9835.0733.59
ubuntu1404-325:46.795:51.98219.66223.6424.1225.22
ubuntu1404-64 6:33.96 5:51.98 254.39 223.64 31.64 25.22
ubuntu1410-64 9:11.83 8:49.15 366.90 347.71 51.84 51.89
ubuntu1504-64 6:38.06 6:07.03 257.19 237.65 26.56 24.22

@rvagg
Copy link
Member

rvagg commented Jun 14, 2015

thanks for the numbers, this lgtm I guess

@jbergstroem
Copy link
Member

LGTM from me as well.

Trott added a commit that referenced this pull request Jun 14, 2015
Expose `common.refreshTmpDir()` and only call it
for tests that use common.tmpDir or common.PIPE.

A positive side effect is the removal of a code
smell where child processes were detected by the
presence of `.send()`. Now each process can decide
for itself if it needs to refresh tmpDir.

PR-URL: #1954
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
@Trott
Copy link
Member Author

Trott commented Jun 14, 2015

Merged in 7c79490

@Trott Trott closed this Jun 14, 2015
@rvagg rvagg mentioned this pull request Jun 16, 2015
@Trott Trott deleted the export-tmpdir branch January 9, 2022 22:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants