A quick test didn't show meaningful performance difference for the generated parser between -Os and -O0, but more tests are needed.

(Some parsers -- not gonna name and shame -- take an extraordinary amount of time and memory to compile to wasm, so trying to reduce that is worth it.)

The point of the -Os is for code size, not performance. Did you compare the size of the binaries?

Yes. The result with -00 is actually smaller (by 2k, so no big difference). Of course, that was just a single badly-behaved parser, so I'd like to check a few more.

Ok, here's a small test of 0.26.3 (with binaryen installed) vs. master vs. this PR vs. --no-wasm-opt only (all using wasi-sdk rather than emscripten), size [bytes] and time [s]:

So... not very conclusive. For complex parsers, -O0 makes a noticeable difference in compilation time, and it's a toss-up whether that increases or decreases size (and by how much). The double wasm-opt run does seem to make a difference in some cases, but only by a (IMO) negligible amount.

In any case, the real issue here is memory pressure: the vim parser requires ~9 Gb sustained, spiking to >20 Gb, which completely throttles the github runner for the release workflow (which takes 40 minutes o.O). Note that this is specific to WASM; normal tree-sitter b takes ~1s and ~300Mb. So it's probably worth looking into WASM-specific options (and trying to find out why that parser tanks clang so catastrophically...)

So... not very conclusive. For complex parsers, -O0 makes a noticeable difference in compilation time, and it's a toss-up whether that increases or decreases size (and by how much). The double wasm-opt run does seem to make a difference in some cases, but only by a (IMO) negligible amount.

Would it make sense/be helpful to accept the optimization level as a flag? The double -OS seems to make a fairly small difference in final size, but can greatly increase time so this seems like a fair tradeoff. Maybe we could make -O0 the default but allow -Os via the CLI?

Since (in a perfect world) the wasm artifacts are built with a standard release workflow, I don't think that would be worth it. I think the best compromise for now is to keep -Os in the build and instead try to find out for which parsers the memory usage explodes and why. Ideally, this can then be fixed on the parser side.

Thanks for collecting this data @clason . I agree that we want it to be standardized (and building wasm artifacts as release artifacts is gonna be fantastic).

I think this upstream issue matches what we're seeing in tree-sitter-vim: llvm/llvm-project#47793