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

Avoid iterating files when --exact is passed in #49

Merged
merged 2 commits into from
Apr 25, 2024

Conversation

zaneduffield
Copy link
Contributor

This fixes a quadratic performance issue in which the test directories are iterated for every test case when run under nextest.

Fixes #8.

@zaneduffield
Copy link
Contributor Author

@sunshowers I wasn't exactly sure how the testing should be implemented.

The only existing test justs run the harness! macro over a test directory and doesn't really assert anything. I figure that there would need to be some higher level integration test that runs another binary built with the harness! macro (assuming that the system has cargo-nextest installed), and makes assertions about its output.

Is that the sort of thing you had in mind?

Copy link
Member

@sunshowers sunshowers left a comment

Choose a reason for hiding this comment

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

This is awesome! Thank you, just a couple of minor comments, and some notes below.

The only existing test justs run the harness! macro over a test directory and doesn't really assert anything. I figure that there would need to be some higher level integration test that runs another binary built with the harness! macro (assuming that the system has cargo-nextest installed), and makes assertions about its output.

Haha, good question. Definitely something we'd like to address eventually with the libtest JSON output or similar, but we're not quite there yet. In particular we don't currently have deserializers for the libtest format; nextest-rs/nextest#1152 has tests for it.

But we can definitely do some kinds of testing. Some things to test against would be:

  • in the test environment, we have an assertion against hitting the full scan (this can be controlled via an internal-only env var)
  • the human-readable output has the right "Summary" line in it. I know it's documented to not be stable -- but it is part of the nextest org, and if it changes we can just fix it.

src/runner.rs Outdated
.collect();

match exact_tests.len() {
0 if is_nextest() => {
Copy link
Member

Choose a reason for hiding this comment

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

Could this just have an outer if is_nextest() condition?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could, and that would be fine.
I wrote it like this because it does the cheap part (length comparison) first and the (relatively) expensive part (env var string comparison) second. It's never going to matter performance-wise to just always check the environment variable. I'll do it that way.

src/runner.rs Outdated
}

fn is_nextest() -> bool {
std::env::var_os("NEXTEST").is_some_and(|val| val.eq("1"))
Copy link
Member

Choose a reason for hiding this comment

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

Can this be val == "1"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure

Copy link

codecov bot commented Apr 23, 2024

Codecov Report

Attention: Patch coverage is 93.00000% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 88.69%. Comparing base (2c6057a) to head (32942ad).
Report is 6 commits behind head on main.

Files Patch % Lines
src/runner.rs 86.27% 7 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #49      +/-   ##
==========================================
+ Coverage   86.33%   88.69%   +2.36%     
==========================================
  Files           4        4              
  Lines         139      230      +91     
==========================================
+ Hits          120      204      +84     
- Misses         19       26       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@zaneduffield
Copy link
Contributor Author

It seems I used a feature (is_some_and) that was unstable in Rust 1.66 (the MSRV I presume).

Maybe this project could be using the new MSRV clippy lint? I think in theory it would lint a case like this when running on a newer version of rust.

@sunshowers
Copy link
Member

Maybe this project could be using the new MSRV clippy lint? I think in theory it would lint a case like this when running on a newer version of rust.

I hadn't heard of this! Sure, happy to take a change for it.

@sunshowers
Copy link
Member

sunshowers commented Apr 23, 2024

Ahh looks like it's the new incompatible_msrv lint: rust-lang/rust-clippy#12160. But it looks like it's in Rust 1.78 and above, and we're using stable (1.77) to run Clippy against.

@sunshowers
Copy link
Member

@zaneduffield
Copy link
Contributor Author

Ahh looks like it's the new incompatible_msrv lint: rust-lang/rust-clippy#12160. But it looks like it's in Rust 1.78 and above, and we're using stable (1.77) to run Clippy against.

OK maybe an improvement for the future, then.

@sunshowers
Copy link
Member

Yeah -- given that it's enabled by default in 1.78, hopefully it'll just happen for free though.

@zaneduffield
Copy link
Contributor Author

I think my new integration test is failing in CI because colour is being forced on in the nextest output. I'll see if I can force it back off.

@zaneduffield
Copy link
Contributor Author

Let me know what you think of the new rudimentary integration test.

Copy link
Member

@sunshowers sunshowers left a comment

Choose a reason for hiding this comment

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

Just a few more comments, thanks!

src/runner.rs Outdated Show resolved Hide resolved
tests/run_example.rs Show resolved Hide resolved
tests/run_example.rs Outdated Show resolved Hide resolved
tests/run_example.rs Show resolved Hide resolved
src/runner.rs Outdated Show resolved Hide resolved
src/runner.rs Outdated Show resolved Hide resolved
This fixes a quadratic performance issue in which the test directories are iterated for every test
case when run under nextest.
Copy link
Member

@sunshowers sunshowers left a comment

Choose a reason for hiding this comment

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

Fantastic, thanks!

@sunshowers sunshowers merged commit 54f8020 into nextest-rs:main Apr 25, 2024
7 checks passed
@sunshowers
Copy link
Member

Had to do a few more changes:

  • only check for exact_tests > 1 if the nextest mode is process-per-test: 8bf6f76 (my oversight, should have mentioned this to you)
  • appease the Windows gods: 56c334a

In any case, this is now out as datatest-stable 0.2.8. Thanks for all your hard work!

@zaneduffield
Copy link
Contributor Author

Had to do a few more changes:

  • only check for exact_tests > 1 if the nextest mode is process-per-test: 8bf6f76 (my oversight, should have mentioned this to you)

Makes sense

  • appease the Windows gods: 56c334a

Oops! I should have remembered that : isn't a valid windows file character...

In any case, this is now out as datatest-stable 0.2.8. Thanks for all your hard work!

You're welcome

@zaneduffield zaneduffield deleted the runExactTest branch April 25, 2024 12:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix quadratic performance with nextest
2 participants