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

humility test suite could be less needlessly cruel #451

Open
hawkw opened this issue Mar 9, 2024 · 0 comments
Open

humility test suite could be less needlessly cruel #451

hawkw opened this issue Mar 9, 2024 · 0 comments

Comments

@hawkw
Copy link
Member

hawkw commented Mar 9, 2024

Running the Humility test suite is one of the most unkind things I've done to my poor laptop: it takes about five minutes to run, and pins every CPU core at 100% for the entire duration:
image

It seems like this is because the complexity of the test suite is multiplicative: it's the number of cores times the number of commands we run. This means that adding a new command increases the total size of the test suite by len(cores), and adding a new core increases the total size of the test suite by len(commands).

There's probably a way to make this a bit less of a brutal dev machine torture test: in at least some cases, such as counters, a command is only "interesting" to run on newer cores that contain the structures the command interprets. Running humility counters on any core except for the one I added specifically to test the counters will just result in humility error: no counters found. So, we probably don't need to run the several different counters commands in the test suite against every core we currently test with. If we added a notion of "only run this command against these cores" to the test framework, we could make it a little less painful to run.

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

No branches or pull requests

1 participant