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

forge test doesn't utilize all available threads for fuzzing/invariants #8898

Open
2 tasks done
Philogy opened this issue Sep 18, 2024 · 6 comments
Open
2 tasks done
Labels
A-testing Area: testing T-perf Type: performance T-post-V1 Area: to tackle after V1

Comments

@Philogy
Copy link

Philogy commented Sep 18, 2024

Component

Forge

Have you ensured that all of these are up to date?

  • Foundry
  • Foundryup

What version of Foundry are you on?

forge 0.2.0 (03ea54c 2024-09-18T16:31:08.207328652Z)

What command(s) is the bug in?

forge test

Operating System

None

Describe the bug

Forge testing is multi-threaded but only on a per test level, for instance if I have 15 different fuzz runs and 224 available threads foundry will assign 15/224 threads with one test each, however some tests take much longer to run than others. Furthermore individual runs of the same test are completely independent. I'd expect different runs to get scheduled to different threads but foundry doesn't seem to do that, leaving a lot of performance on the table.

@Philogy Philogy added T-bug Type: bug T-needs-triage Type: this issue needs to be labelled labels Sep 18, 2024
@grandizzy
Copy link
Collaborator

good point, we're currently limited by proptest test runner but should consider changing this post 1.0 release

@zerosnacks zerosnacks added T-perf Type: performance T-likely-breaking Type: requires changes that can be breaking and removed T-needs-triage Type: this issue needs to be labelled labels Sep 19, 2024
@zerosnacks zerosnacks changed the title forge t doesn't utilize all available threads bug: forge test doesn't utilize all available threads Sep 19, 2024
@Philogy
Copy link
Author

Philogy commented Sep 19, 2024

good point, we're currently limited by proptest test runner but should consider changing this post 1.0 release

This would be an amazing feature to have, would mean an 8-224x speedup depending on the machine I run the tests on

@Philogy
Copy link
Author

Philogy commented Sep 19, 2024

Could there be a temporary workaround where foundry duplicates a given test or invariant for you by the number of available threads and then does total_runs / N runs on each?

I can do it manually but it gets a but unwieldy:
image

also I know either have to do this for all my fuzz tests or run different suites with different profiles

@zerosnacks zerosnacks added the A-testing Area: testing label Sep 19, 2024
@Philogy
Copy link
Author

Philogy commented Sep 19, 2024

@zerosnacks not quite sure I understand how this would be a breaking change or what does T-breaking mean in this context?

How the tests are run should be abstracted away from the end user, no?

@zerosnacks zerosnacks removed the T-likely-breaking Type: requires changes that can be breaking label Sep 19, 2024
@zerosnacks
Copy link
Member

You are correct, we use T-breaking as an internal tag to indicate it would likely require making a breaking change and we should decide whether to include it before or after 1.0. Moving away from proptest would be a huge change but indeed should not be experienced as breaking by the end-user.

@Philogy
Copy link
Author

Philogy commented Sep 19, 2024

I see, good to know thx

@DaniPopes DaniPopes removed the T-bug Type: bug label Sep 22, 2024
@DaniPopes DaniPopes changed the title bug: forge test doesn't utilize all available threads forge test doesn't utilize all available threads for fuzzing/invariants Sep 22, 2024
@grandizzy grandizzy added the T-post-V1 Area: to tackle after V1 label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testing Area: testing T-perf Type: performance T-post-V1 Area: to tackle after V1
Projects
None yet
Development

No branches or pull requests

4 participants