-
Notifications
You must be signed in to change notification settings - Fork 42
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
Memory recording improvements #64
Comments
A naive approach that comes to mind is to have a HashMap (OpCode => bool) that contains info if an OpCode modifies memory, record memory only if the hashmap entry is true. |
yep, great idea! we've since added something similar to foundry: which we use for efficient memory recording as well: so we can move this function in here and do the same trick do you want to take this? |
@mattsse yes, please assign me! |
Oh, it would be good to move |
great! @h3lio5 do you want to take care of that as well? |
@mattsse sure, I'll port it over to revm also. |
Currently, if
https://github.com/paradigmxyz/evm-inspectors/blob/846dec1db14ac42067e7a4bb6a973091cd7eb808/src/tracing/config.rs#L15-L16
is enabled memory, memory is cloned on each step:
https://github.com/paradigmxyz/evm-inspectors/blob/846dec1db14ac42067e7a4bb6a973091cd7eb808/src/tracing/mod.rs#L306-L310
there are only a few opcodes that modify memory, so we can optimize this and only record memory when necessary.
This is also only relevant for the parity vmtrace setting:
https://github.com/paradigmxyz/evm-inspectors/blob/846dec1db14ac42067e7a4bb6a973091cd7eb808/src/tracing/builder/parity.rs#L383-L390
The text was updated successfully, but these errors were encountered: