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

wasm-opt --nm のエントリポイントから始め、commit #6371 で導入された新しいテキストパーサーと以前のパーサーを比較してください。報告された .wast ファイルでリグレッションを再現し、リンクされているプロファイルを使って遅いパスを特定してください。新しいパーサーの動作を維持しながら、以前の約 ~11 秒に近いパフォーマンスを回復できれば完了です。

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?