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

VCS tests: Make smaller Arbitrary repositories to speed up long-tests 4.2x #10588

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

9999years
Copy link
Collaborator

The Arbitrary repo recipes can get quite large due to nesting:

  • RepoRecipes contain a number of groups (TaggedCommits or BranchCommits).
  • Groups contain a number of Commits.
  • Commits contain a number of operations (FileUpdate or SubmoduleAdd).

There's also another wrinkle in that SubmoduleAdds contain a Commit themselves, so square the operationsPerCommit number!

Then, a rough upper bound of the number of git calls required for an arbitrary RepoRecipe is
groupsPerRecipe * commitsPerGroup * operationsPerCommit^2.

The original implementation of these instances, which chose reasonable-sounding size parameters of 5-15, led to a maximum of 1875 operations per test case! No wonder they took so long!

In my tests, this change reduces the time of running the long-tests suite from 429 seconds to 102 seconds (a 4.2x speedup).

@9999years 9999years changed the title VCS tests: Make smaller Arbitrary repositories VCS tests: Make smaller Arbitrary repositories to speed up long-tests 4.2x Nov 22, 2024
@9999years 9999years marked this pull request as ready for review November 22, 2024 21:07
@9999years 9999years added the merge me Tell Mergify Bot to merge label Nov 25, 2024
@mergify mergify bot added ready and waiting Mergify is waiting out the cooldown period merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days labels Nov 25, 2024
The `Arbitrary` repo recipes can get quite large due to nesting:

- `RepoRecipes` contain a number of groups (`TaggedCommits` or `BranchCommits`).
- Groups contain a number of `Commit`s.
- Commits contain a number of operations (`FileUpdate` or `SubmoduleAdd`).

There's also another wrinkle in that `SubmoduleAdd`s contain a `Commit`
themselves, so square the `operationsPerCommit` number!

Then, a rough upper bound of the number of `git` calls required for an
arbitrary `RepoRecipe` is
`groupsPerRecipe * commitsPerGroup * operationsPerCommit^2`.

The original implementation of these instances, which chose
reasonable-sounding size parameters of 5-15, led to a maximum of 1875
operations per test case! No wonder they took so long!

In my tests, this change reduces the time of running the `long-tests`
suite from 429 seconds to 102 seconds (a 4.2x speedup).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days merge me Tell Mergify Bot to merge ready and waiting Mergify is waiting out the cooldown period
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants