-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
feat(forge
): commit state between invariant runs
#5444
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks reasonable
This is incredibly slow though @mattsse — do you think there's another way to do this? If not, we probably shouldn't do this because of performance regressions. |
Hmm, can you help me understand why this has such a big performance regression? We already commit state for all non-test contracts, so it seems surprising that committing state for the test contract would cause this |
Yep, so, it's because we persist the peripheral contract's state in a different way altogether—it's much cheaper since we're not really "growing" the internal executor changeset, but rather collecting the run state and then using this to find the next inputs. For committing the invariant state we'd need to keep the used executor alive, and this means that for each depth of each run, the in-memory db will grow, and it'll get slower and slower as a result |
forge
): commit state between invariant runsforge
): commit state between invariant runs
@mds1 @mattsse nevermind about performance regressions—something was affecting my environment and made builds super slow. Just moved to my new laptop and this is fine. Just tested doing foundryup from this branch commit and the performance difference seems completely negligible. I think we can merge this in if this is truly the case! Just a sanity test, can you test this branch @mds1 ? |
Oh awesome, that's great news! Definitely can test, cc @lucas-manuel @PaulRBerg to sanity test also :) |
Closing, this is not the correct solution to #3005 — i'll followup with the proper fix |
Motivation
Closes #3005.
Solution
Do not drop the executor between runs, but rather use the same executor.