wasmparser: 15-30% performance regressions from v228 -> v229

[Robbepop]

I just finished updating Wasmi to the new wasm-tools v229 coming from v228.

• Roughly 15% performance regressions across the board.
• Up to 30% performance regressions when Wasmi translation was lazy and thus wasmparser parsing and validation made up a larger chunk of the work. So that's probably the real regression in wasmparser.

Wasmi PR: wasmi-labs/wasmi#1501

Benchmarking before and after revealed the following performance regressions:

[alexcrichton]

Would you be able to help profile and track down where this is coming from? Perhaps via bisection?

[Robbepop]

Would you be able to help profile and track down where this is coming from? Perhaps via bisection?

Yes I can do that.

[Robbepop]

@alexcrichton The 30% parse and validation regression first appears here

commit 0354dde10184d7ff813282a2837d9a4ed8e766e6
Author: Keith Winstein <[email protected]>
Date:   Tue Apr 15 14:09:45 2025 -0700
    wasmparser: detect "malformed" cases in parser alone (without validator) (#2134)

The commit right before it does not have the regression:

commit 90c156ff15a81cb0360fb949e6504a4799d3b5cc
Author: Alex Crichton <[email protected]>
Date:   Tue Apr 15 14:34:21 2025 -0500
    Prevent over-deep type hierarchies in wasm-smith (#2143)

I have also ran benchmarks on the newly released wasmparser v0.230.0 but it seems to be suffering from the same performance regressions as wasmparser v0.229.0 does.

cc @keithw

[keithw]

I can replicate this in-repo with cargo bench -p wasmparser -- parse/tests ; let me try to produce a flamegraph and take a look asap (but please don't let me stop anybody else).

[keithw]

I did some measurements on parsing (without validating) a single huge module on an unloaded AMD Ryzen 7 PRO 4750U, comparing two release builds built with rustc 1.86.0 (05f9846f8 2025-03-31).

For the "before", I tested the commit just before that PR (90c156f), backporting the "full parse" logic from https://github.com/bytecodealliance/wasm-tools/blob/main/src/lib.rs#L299 (with the exception of the ops.finish()?; line since the "before" parser doesn't have a finish function to check anything at the end of a function).

For the "after", I used that PR (0354dde).

In both cases I tested wasm-tools parse without output (i.e. removing https://github.com/bytecodealliance/wasm-tools/blob/main/src/bin/wasm-tools/parse.rs#L25). I ran the command under perf stat a few hundred times and recorded the cycles counter. I ran it enough that the standard error of the mean is <1M cycles for both measurements.

I was surprised to find that in this "single huge module" test, I didn't see a regression:

Commit	mean cycle count	diff
Before	823,830,564
After	813,671,062	-1.2%

For parsing+validation, again with this single huge module, I see a roughly 3% slowdown on running cargo validate, but nothing like 15-30%.

On the other hand, cargo bench on the spec and local testsuite (which has thousands of mostly tiny modules) definitely documents a regression. So I'm wondering... are you seeing a big slowdown on parsing or parse+validating individual (large) modules, and if so, are you able to share an example module? Or should we be looking at a slowdown related to parser creation/startup time on lots of small modules, and that's getting washed out in the noise on my "single huge module" test?