bytecodealliance / bytecodealliance/wasm-tools
`wasmparser`: Wasm validation optimization idea
- Dominant language
- Rust
- Stars
- 1.8k
- Forks
- 351
- Avg merge
- 16h 57m
- Merged PRs (30d)
- 38
Description
Hi, I was thinking about how to further optimize the `wasmparser` Wasm validation performance because at least in `wasmi` it takes up quite a fraction of the overall time when compiling Wasm blobs.
The `wasmparser` crate has lots of runtime checks in place to enable or disable most Wasm proposals. Those checks in summary might be costly. (Needs proof.)
The idea is that there usually are common and uncommon profiles of Wasm feature selections.
E.g., many users probably still rely on Wasm MVP or simply enable all (stable) Wasm features.
For those common profiles we could specialize the `FuncValidator` type by making it generic over a trait:
```rust
pub trait WasmProfile {
fn multi_value(&self) -> bool;
fn reference_types(&self) -> bool;
fn floats(&self) -> bool;
// etc...
}
```
And now we could have a simple implementation for the generic fallback case, based on the `WasmFeatures` that simply forwards its fields for the trait methods. This should be as fast or as slow as the current implementation.
But if we pre-analyze one of the common Wasm profiles, e.g. where all features are enabled, we could provide the `FuncValidator` with a `WasmProfile` type that forwards constants with which the Rust/LLVM can fully optimize away all or most of those checks.
Is that feasible? Am I missing something important? What do you think about this? Unfortunately I have not yet made perf tests for this so my perfs claims might all be wrong because I underestimate the power of the branch predictor.
For example:
```rust
impl WasmProfile for DefaultWasmProfile {
#[inline(always)] fn multi_value(&self) -> bool { true }
#[inline(always)] fn reference_types(&self) -> bool { true }
#[inline(always)] fn floats(&self) -> bool { true }
// etc...
}
```
`#[inline(always)]` probably not even needed.
Contributor guide
Assessment
This issue has not been assessed yet.