A modern programming language that makes developers happier.

kotlinlang

I made a quick try adding <https://github.com/Kotlin/kotlinx.serialization?tab=readme-ov-file#introduction-and-references|a very simple use case of Kotlin Serialization> to <https://github.com/sdeleuze/wasm-footprint/tree/main/kotlin|my WASI sample> which has Binaryen optimization enabled:
• Adding the plugin and depedency adds 8K (52K to 60K)
• Serialization with `StringFormat.encodeToString` adds 442K (60K to 502K)
• Deserialization with `decodeFromString` adds 604K (60K to 664K) 
Given Kotlin Serialization compile-time step and Bynarien Dead Code Elimination capabilities, I am a bit frustrated by this footprint which may be ok-ish for `wasmWasi` but not for `wasmJs`, and suspect there may be optimizaton to be made here that could be beneficial to both.

Any thoughts on if this is due to Kotlin/Wasm generating suboptimal bytecode that does not allow dead code elimination, or if there is more something to do on Kotlin Serialization side (potentialy in the plugin) to make some code unreachable and allow more aggressive optimizations?

I see some mentions of Coroutines in the `.map` file, and I know it has not a small cost in terms of footprint and wonder if we could get rid of it for such simple use case.

The related branch is available <https://github.com/sdeleuze/wasm-footprint/tree/kotlin-serialization|here>.

I am surprised that Coroutines appears for serialization? Why would that be?

I see 663K before binaryen and 225K after. This is still worth looking into, but 3x less scary :slightly_smiling_face:

You can see optimised wasm by following:
```$ ./gradlew :compileProductionExecutableKotlinWasmWasiOptimize
$ ls -lhS build/compileSync/wasmWasi/main/productionExecutable/optimized/add-wasm-wasi.wasm ```
As for coroutines, as far as I see it uses coroutines-based `DeepRecursiveFunction` from standard library to implement <https://github.com/Kotlin/kotlinx.serialization/pull/1596|deep JSON generation> using recursion. I don’t know how much footprint it brings in particular. It does not depend on `kotlinx.coroutines` library (you would see `kotlinx.coroutines` pacakges in `.map` files instead of small stdlib `kotlin.coroutines` )

Ah thanks, much better indeed. Wasn’t using the right task I guess.

I myself learned about this task just now :slightly_smiling_face:
You would normally do a `*Distibution` task in `wasmJs`, and it would include optimized version, but it is missing in `wasmWasi`. KGP for `wasmWasi` needs some love.

Maybe <https://youtrack.jetbrains.com/issue/KT-64553/K-Wasm-enable-binaryen-by-default-in-production-builds|https://youtrack.jetbrains.com/issue/KT-64553/K-Wasm-enable-binaryen-by-default-in-production-builds> could fix that by providing the nice optmized artifact for production builds on both `wasmJs` and `wasmWasi` with the regular production/distribution tasks (without the additional optimized directory).

This is a separate important step :+1:
Current `wasmWasi` problem is that `:compileProductionExecutableKotlinWasmWasiOptimize` and `build/compileSync` are designed to be internal, intermediate things, and not a part of developer UX.