-
Notifications
You must be signed in to change notification settings - Fork 43
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
fix(oppool): use efficient pack length #371
Conversation
058569b
to
771977b
Compare
@@ -164,7 +164,7 @@ impl PoolOperation { | |||
} | |||
|
|||
pub fn size(&self) -> usize { | |||
self.uo.pack().len() | |||
USER_OPERATION_PACKED_LEN |
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.
Was kind of confused, this is just a constant no matter what the size of the user op is right? Was it not at some point?
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.
thats a good question, let me look into the packed size of a specific uo and make sure that constant is still correct
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.
the original discussion referenced in #81 seemed to imply that this value is dynamic, need to make sure we are not confusing packed vs actual size of the UO throughout the codebase
@@ -164,7 +164,7 @@ impl PoolOperation { | |||
} | |||
|
|||
pub fn size(&self) -> usize { | |||
self.uo.pack().len() | |||
self.uo.mem_size() |
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.
This size function ends up only being used for managing the pool size, so using the memory size here. Should we also be including the memory overhead of the other fields of PoolOperation
?
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.
Yeah, good thought. Makes sense to move this mem_size()
function one level up to PoolOperation
.
crates/types/src/user_operation.rs
Outdated
@@ -61,7 +64,43 @@ impl UserOperation { | |||
} | |||
|
|||
/// Packs the user operation into a byte array, consistent with the entrypoint contract's expectation | |||
pub fn pack(&self) -> Bytes { | |||
pub fn abi_encode(&self) -> Bytes { |
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.
Does ethers
not already offer a function for this?
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.
good point, now just using the .encode()
function from the AbiEncode
trait
crates/types/src/user_operation.rs
Outdated
} | ||
|
||
/// Gets the byte array representation of the user operation to be used in the signature | ||
pub fn pack_signature_message(&self) -> Bytes { |
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.
I think a better name here would be pack_for_hash
, since the signature gets calculated from the hash.
cf3d11a
to
198a16a
Compare
crates/pool/src/mempool/mod.rs
Outdated
pub fn mem_size(&self) -> usize { | ||
std::mem::size_of::<Self>() | ||
+ self.uo.mem_size() | ||
+ std::mem::size_of::<Vec<EntityType>>() |
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.
Assuming that this is for entities_needing_stake
is this not accounted for in std::mem::size_of::<Self>()
?
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.
yep! actually made a mistake about how size_of works, it actually is able to recursively get the size of everything that gets allocated to the stack, so calling self.uo.mem_size() here would be double counting.
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.
🚢
198a16a
to
55e780a
Compare
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.
🚢
Closes #81
Proposed Changes