~+700% regression in wasm-opt --nm performance from Emscripten 3.1.38 -> 4.0.19

Open
#8,406 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
wasm
Domain
compilers, performance

Research direction

Start with the wasm-opt --nm entry point and compare the new text parser introduced in commit #6371 against the previous parser. Reproduce the regression on the reported .wast file and use the linked profiles to identify the slow path. Done means restoring performance near the former ~11 seconds while preserving the new parser's behavior.

Written by the indexing model from the issue text.

Description

Previously we were using Emscripten 3.1.38.

In some of our code stripping related unit tests, we are running wasm-opt --nm on a .wast file. In old Emscripten 3.1.38, this step took ~11 seconds.

After updating to Emscripten 4.0.19, the same wasm-opt --nm step is now taking about 87 seconds, about ~8x increase from before.

Bisecting the issue, the performance regression has arrived in #6371:

commit 956d2d89d530012885c1f88c87bf8b872c187b70 (HEAD)
Author: Thomas Lively tlively@google.com
Date: Thu Apr 25 14:55:12 2024 -0700

[Parser] Enable the new text parser by default (#6371)

The new text parser is faster and more standards compliant than the old text
parser. Enable it by default in wasm-opt and update the tests to reflect the
slightly different results it produces. Besides following the spec, the new
parser differs from the old parser in that it:

 - Does not synthesize `loop` and `try` labels unnecessarily
 - Synthesizes different block names in some cases
 - Parses exports in a different order
 - Parses `nop`s instead of empty blocks for empty control flow arms
 - Does not support parsing Poppy IR
 - Produces different error messages
 - Cannot parse `pop` except as the first instruction inside a `catch`

CC @tlively

A samply profile of the slow behavior can be observed https://share.firefox.dev/4aUcR0c

Image

If I back out to the previous commit and profile that, then I get the following looking profile:

https://share.firefox.dev/4sc8owW

Image

I wonder if there might exist any optimizations that could bring the performance of the new parser up to par with the old one?

Dominant language
WebAssembly
Stars
8.6k
Forks
885
Avg merge
1d 20h
Merged PRs (30d)
64

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WebAssembly/binaryen

All issues in WebAssembly/binaryen

Similar issues

More Compilers issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.