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

Try to optimize Key::encode #62

Open
uint opened this issue Sep 18, 2024 · 2 comments
Open

Try to optimize Key::encode #62

uint opened this issue Sep 18, 2024 · 2 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@uint
Copy link
Collaborator

uint commented Sep 18, 2024

It might be worthwhile to return something like Cow from Key::encode. Some common cases (String?) don't need us to compute a value.

@uint uint added good first issue Good for newcomers help wanted Extra attention is needed labels Sep 18, 2024
@webmaster128
Copy link
Member

I think the most prominent use case for such an optimization the use of Addr in keys (map from user to whatever). Using Addr::as_bytes (returns &[u8]) when composing the final key save an intermediate allocation of 40-65 bytes for the address.

@webmaster128
Copy link
Member

There can also be a 3rd option here, data in arrays:

enum Key<'a> {
    Borrowed(&'a [u8]),
    Short1([u8; 1]), // can store 8 bit value
    Short2([u8; 2]), // can store 16 bit value
    Short4([u8; 4]), // can store 32 bit value
    Short8([u8; 8]), // can store 64 bit value
    Owned(Vec<u8>)
}

This enum should be 12 bytes large in Wasm (same as Vec<u8>) due to optimizations. I tested this in the playground but only on a 64bit target.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants