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

fix(oppool): use efficient pack length #371

Merged
merged 2 commits into from
Sep 21, 2023
Merged

fix(oppool): use efficient pack length #371

merged 2 commits into from
Sep 21, 2023

Conversation

alex-miao
Copy link
Collaborator

@alex-miao alex-miao commented Sep 15, 2023

Closes #81

Proposed Changes

  • make it so that we don't need to actually do the packing to determine the size

@@ -164,7 +164,7 @@ impl PoolOperation {
}

pub fn size(&self) -> usize {
self.uo.pack().len()
USER_OPERATION_PACKED_LEN
Copy link
Collaborator Author

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?

Copy link
Collaborator

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

Copy link
Collaborator Author

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()
Copy link
Collaborator Author

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?

Copy link
Collaborator

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.

@@ -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 {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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

}

/// Gets the byte array representation of the user operation to be used in the signature
pub fn pack_signature_message(&self) -> Bytes {
Copy link
Collaborator

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.

@alex-miao alex-miao force-pushed the alex/pack-len branch 2 times, most recently from cf3d11a to 198a16a Compare September 20, 2023 18:20
pub fn mem_size(&self) -> usize {
std::mem::size_of::<Self>()
+ self.uo.mem_size()
+ std::mem::size_of::<Vec<EntityType>>()
Copy link
Collaborator

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>()?

Copy link
Collaborator Author

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.

Copy link
Collaborator

@dancoombs dancoombs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

Copy link
Collaborator

@dancoombs dancoombs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

@alex-miao alex-miao merged commit 2a00be5 into main Sep 21, 2023
5 checks passed
@alex-miao alex-miao deleted the alex/pack-len branch September 21, 2023 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pool: add pack_len() method to UO for size tracking
3 participants