grandizzy

in latest builds this is caught with default settings but run depth increased (`max_calldata_fuzz_dictionary_addresses` setting was retired since we now support fixtures https://book.getfoundry.sh/forge/fuzz-testing#fuzz-test-fixtures), e.g. with a depth of 500 ```...

Agree, we should revisit all defaults and update them to more relevant values, like - `depth` to 500 (For example echidna uses a default `seqLen: 100` and `testLimit: 50000` which...

additional perf improvements were added, noticeably https://github.com/foundry-rs/foundry/pull/7756 could you please recheck and see if that helped? 🙏 @Philogy @frontier159

> I would like invariant tests (foundry's stateful fuzz tests) to be a bit more performant. While recently doing a larger fuzzing campaign on my local computer I noticed that...

@frontier159 thank you, will check the offline / online improvements, do you have a simple test I could use to debug? Re runs with higher depth being slow - I...

@mds1 do we want to expose a new config for the number of threads to run tests or just document that it can be changed by using `RAYON_NUM_THREADS` env var?

If I am not missing something you can already do that by specifying the block number to fork in `createSelectFork` cheatcode https://book.getfoundry.sh/cheatcodes/create-select-fork#examples The block number can be read as an...

just noticed https://github.com/foundry-rs/foundry/issues/3607 I think the approach of global invariant reporter could be a good foundation of adding such, wdyt?

> Have you tested this in the context of multiple other unit and fuzz tests? It looks like it will constantly get "overwritten" by the other test results that stream...

A different approach using `indifcatif` library