Skip to content

wasmparser: Optimize Locals::get type query #2197

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

Merged
merged 6 commits into from
May 21, 2025

Conversation

Robbepop
Copy link
Collaborator

@Robbepop Robbepop commented May 21, 2025

When looking through the code I saw that Locals::all field unnecessarily pushes all locals, even the ones that have already been covered in the first vector. This further slows down the binary_search call due to having to search through all the unnecessary indices.

This led to a modest speed-up of ~1-2% though I doubt that the current set of benchmarks really cover this scenario and therefore the gains might be higher for some real world Wasm files with many large functions.

I changed the types of MAX_WASM_FUNCTION_LOCALS and MAX_LOCALS_TO_TRACK because they are only used at those locations and the new typing no longer necessitates casts.

image

Robbepop added 5 commits May 21, 2025 10:57
We rename because this field will no longer store _all_ locals, but only the ones that are not also stored in the `first` field.
@Robbepop
Copy link
Collaborator Author

Robbepop commented May 21, 2025

CI tests fail because this PR uses core::iter::repeat_n which got stabilized in Rust 1.82 but the MSRV of wasm-tools seems to be Rust 1.76. Shall I use the inferior (for performance) core::iter::repeat(..).take(n) approach or shall we bump the MSRV?

https://github.com/bytecodealliance/wasm-tools/blob/main/Cargo.toml#L89-L95

edit: For now I went with the repeat().take() approach since it is easily fixable once the MSRV bumps since there is a clippy lint for it.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

Thanks for this! I'll go ahead and flag this for merge.

As for MSRV, I'm not 100% sure how best to handle this. I feel that Wasmtime's 2-latest-rustc-version is a bit too aggressive for this repository given the broader use that's intended here. Freezing to just one version though is also something I don't think is tenable. I've roughly been thinking that "current - 10" is a reasonable enough window for this workspace, but I haven't set up automation or anything like that to such effect.

@alexcrichton alexcrichton added this pull request to the merge queue May 21, 2025
@Robbepop
Copy link
Collaborator Author

@alexcrichton thanks!

current - 10 roughly equals to a Rust version that has been stable for just over a year. Probably a decent foundation for such a widely used dependency.

Merged via the queue into main with commit 84d3a4c May 21, 2025
32 checks passed
@alexcrichton alexcrichton deleted the rf-optimize-locals-get-type branch May 21, 2025 16:56
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