Closed
Description
AFAICT debuginfo tests are way slower than other kinds of tests due to being executed sequentially (I haven't properly checked the source but I couldn't see many threads in htop
and it looked sequential).
This is especially noticeable on machines with 16 or more hardware threads, where other test suites make visible progress at significantly faster rates.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
eddyb commentedon May 29, 2020
The other thing I've noticed before but I wasn't sure about, is that there seems to be no skipping of previously-passing tests.
tromey commentedon Mar 18, 2022
src/tools/compiletest/src/main.rs says:
This dates back to 2014 (and maybe before but I didn't dig any deeper):
Maybe such old versions of lldb aren't relevant any more.
tromey commentedon Mar 18, 2022
Removing that line sure seems to help. The question then is whether it can be removed. @michaelwoerister - you added that, do you recall?
I don't know anything about skipping already-passed tests.
michaelwoerister commentedon Mar 18, 2022
As far as I remember, back in 2014 LLDB tests failed reliably when run in parallel. That was the only reason why we made them run one at a time. If that's not a problem anymore, we should run them in parallel, yes.
For GDB and CDB tests are already running in parallel, right?
tromey commentedon Mar 18, 2022
I believe so.
Re-enable parallel debuginfo tests
Rollup merge of rust-lang#95072 - tromey:parallel-debug-tests, r=tmiasko
tromey commentedon Mar 18, 2022
I think this already happens, since I see this
i
output:tmiasko commentedon Mar 18, 2022
I think I fixed this back in #68391 (the spurious hash mismatch mentioned in the pull request description).
3 remaining items