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

[juj]

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 956d2d8 (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

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

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

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

[tlively]

Interesting, as the commit message says, we measured the new parser as being significantly faster than the old parser at the time. I wonder if you're triggering some pathological (e.g. quadratic) behavior. I'll take a closer look at the profiles to see if anything stands out, but it would also be helpful to have a reproducer, if possible. Maybe you could use wasm-reduce to get a shareable module that still causes the performance difference?

[tlively]

And just to verify, these are release builds of wasm-opt, right?