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

Small optimizations for Symbol. #1520

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

dmkozh
Copy link
Contributor

@dmkozh dmkozh commented Feb 20, 2025

What

  • Use Symbol::try_from_val in map_new_from_linear_memory which both ensures the proper symbol validation (which doesn't happen now) and makes the conversion slightly cheaper
  • Convert slices to symbols based on their length instead of re-trying the conversion for both lengths. This is really tiny performance-wise, but makes the code simpler to maintain by reducing the risk of accidentally creating a symbol with incorrect length

Both are non-functional protocol changes: while they have to go into env for the new protocol, the only observable change is the slight reduction of CPU costs.

Why

Implementation cleanup/optimization

Known limitations

N/A

@dmkozh dmkozh requested review from graydon, sisuresh and a team as code owners February 20, 2025 00:15
- Use `Symbol::try_from_val` in `map_new_from_linear_memory` which both ensures the proper symbol validation and makes the conversion slightly cheaper
- Convert slices to symbols based on their length instead of re-trying the conversion for both lengths. This is really tiny performance-wise, but makes the code simpler to maintain by reducing the risk of accidentally creating a symbol with incorrect length

Both are non-functional protocol changes: while they have to go into env for the new protocol, the only observable change is the slight reduction of CPU costs.
nju
Copy link
Member

@leighmcculloch leighmcculloch left a comment

Choose a reason for hiding this comment

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

Previous attempts to optimise Symbol code have caused significant changes guest side that was unintuitive and unexpected.

Does this function ever get triggered contract side? If yes, what impact does this have on WASM size and instructions this translates into on the contract side?

Although, I expect and hope this function doesn't get called contract side because doing so would embed Symbol encoding logic into contracts.

On the surface this looks fine to me.

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.

2 participants