The longest task in my gradle build is `compilePro...

# webassembly

[Carter]

The longest task in my gradle build is compileProductionExecutableKotlinWasmJsOptimize , at over 7 minutes for a fairly small application (that otherwise only takes 4 minutes to build when the wasmJs target is disabled). Are there any configurable options that could improve the performance of this task? I imagine the binaryen optimization is what is taking the majority of this time.

[Rok Oblak]

Wasm runs were significantly faster on my machine when I gave the IDE access to more memory:
https://kotlinlang.slack.com/archives/CDFP59223/p1719777779070979

(I only stumbled on this because at one point my build failed due to out of memory)

[Svyatoslav Kuzmich [JB]]

This particular task launches a native binaryen wasm-opt process that won’t be affected by JVM flags. You can configure binaryen flags in Gradle. I’ll recreate the default setup, separating the required and optional flags:

tasks.withType<org.jetbrains.kotlin.gradle.targets.js.binaryen.BinaryenExec> {
    binaryenArgs = mutableListOf(
        // Required flags:
        "--enable-gc",
        "--enable-reference-types",
        "--enable-exception-handling",
        "--enable-bulk-memory",
        "--enable-nontrapping-float-to-int",

        // Optional flags (can be removed):
        "--inline-functions-with-loops",
        "--traps-never-happen",
        "--fast-math",
        "-O3",
        "-O3",
        "--gufa",
        "-O3",
        "-O3",
        "-Oz",
    )
}

You can then remove some of the -O3 flags to speed it up. See https://github.com/WebAssembly/binaryen/wiki/GC-Optimization-Guidebook for more details.

[Carter]

Thank you for pointing me to that task, which gives me some things to play with. I found setting the environment variable export BINARYEN_PASS_DEBUG=1 provides debug info on each optimization.

On my Mac Studio, the slowest (by an order of magnitude) steps are:
[PassRunner] running pass: dae-optimizing... 9.05247 seconds.
[PassRunner] running pass: inlining-optimizing... 10.6519 seconds.

On a GitHub Actions larger runner (8 core ARM 64 Ubuntu), the slowest two steps are:
[PassRunner] running pass: dae-optimizing... 64.1798 seconds.
[PassRunner] running pass: inlining-optimizing... 88.8491 seconds.

Can you think of a reason why these would be 10x slower on CI?

[Carter]

I’m going to do some testing to see the size impact of skipping those steps and will report back.