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

perf: cache Evm/Handlers in Executor #8380

Open
DaniPopes opened this issue Jul 6, 2024 · 0 comments
Open

perf: cache Evm/Handlers in Executor #8380

DaniPopes opened this issue Jul 6, 2024 · 0 comments
Labels
A-evm Area: EVM A-internals Area: internals T-perf Type: performance

Comments

@DaniPopes
Copy link
Member

Component

Other (please describe)

Describe the feature you would like

Every time we make a call using Executor we create a new Evm. This creates the context, handlers, and instruction table, which then also have to be cleaned up after the call is done.

This is relatively inexpensive in a normal test/fuzz test which consumes hundreds of thousands of gas. However, for very short calls which consume very little gas, like in invariants, the time spent in Evm initialization and destruction is often most of the time spent in that entire call (>50%).

We can avoid this by caching the evm / instruction table / handlers. There are currently a few complications, including missing Clone, Send and Sync for some of these types.

Additional context

No response

@DaniPopes DaniPopes added A-evm Area: EVM T-perf Type: performance labels Jul 6, 2024
@zerosnacks zerosnacks added the A-internals Area: internals label Jul 16, 2024
@zerosnacks zerosnacks changed the title Cache Evm/Handlers in Executor perf: cache Evm/Handlers in Executor Jul 16, 2024
@zerosnacks zerosnacks added this to the v1.0.0 milestone Jul 26, 2024
@jenpaff jenpaff removed this from the v1.0.0 milestone Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-evm Area: EVM A-internals Area: internals T-perf Type: performance
Projects
None yet
Development

No branches or pull requests

3 participants