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

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

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?

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.