Skip to content

chore: speed up miri workflow & include arrow-cmp - #10580

Open
Jefffrey wants to merge 4 commits into
apache:mainfrom
Jefffrey:bump-miri-partitions
Open

chore: speed up miri workflow & include arrow-cmp#10580
Jefffrey wants to merge 4 commits into
apache:mainfrom
Jefffrey:bump-miri-partitions

Conversation

@Jefffrey

@Jefffrey Jefffrey commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

before #10507 (running miri on more crates), miri took about 15-20 minutes on average. with the new PR it increased to a bit over 30 minutes because we're running more tests.

increase the partitions count to try get average runtime down, also use taiki-e to install nextest via binary to shave off 3 minutes spent on compiling nextest from source.

also include arrow-cmp (new crate) in the miri execution

@Jefffrey Jefffrey changed the title chore: bump miri workflow partitions & include arrow-cmp chore: speed up miri workflow & include arrow-cmp Aug 7, 2026
@Jefffrey Jefffrey added the development-process Related to development process of arrow-rs label Aug 7, 2026
@Jefffrey

Jefffrey commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

looks like 20 minutes now

@Jefffrey
Jefffrey marked this pull request as ready for review August 7, 2026 13:06
@alamb

alamb commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

looks like 20 minutes now

It is 20 minutes but with 6 executors (so a total CPU time of 120 min / 2 hours) 🤔

Screenshot 2026-08-07 at 10 42 05 AM

However, that appears to me what the current main uses too (just in 4 parallel runs)

Screenshot 2026-08-07 at 10 43 11 AM

Maybe we should consider reducing MIRI on PRs (and only run it on merge to main) 🤔

@alamb alamb left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Seems better than what is on main 👍 thanks @Jefffrey

@Jefffrey

Jefffrey commented Aug 8, 2026

Copy link
Copy Markdown
Contributor Author

yeah was mainly interested in reducing the workflow time, even though total cpu time takes the same amount

Maybe we should consider reducing MIRI on PRs (and only run it on merge to main)

one thing to consider with this is if new tests are added, they could have issues such as taking too long to run or miri not supporting them (e.g. hits asm), so ideally we'd wanna still catch those during PR instead of fixing after the fact on main

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

development-process Related to development process of arrow-rs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants