Clojurians Log v2
cljs-dev 2026-10-04
@hhausman nice! I believe any WASM under 4K can be compiled on the client w/o issue - next question would just be whether that's slower than what we already have. searching the web seems to imply that a bunch of work has been done to lower the overhead in Chrome & Firefox. I'm curious about Safari. If the other browsers are good enough, maybe we can conditionally execute one or the other.
I didn't know about the OCaml reference implementation for encoding/decoding WAT/WASM https://github.com/WebAssembly/spec/tree/main/interpreter/binary
@dnolen fun!
---
> next question would just be whether that's slower than what we already have
I haven't measured, but my gut feeling is that for a single number it would be slower, but if we were in a situation where we had a typed array of 32 bit integers there would be some crossover point (in the size of that array) where looping over them on the wasm side (or even investigating vectorized wasm popcnt) could win.
> I didn't know about the OCaml reference implementation for encoding
I didn't know about that either - and it opens up lots of fun ideas. What's our analogy for C's __asm__ ? simple_smile
From your link:
https://github.com/WebAssembly/spec/blob/970c4116e644e2bf7acb39aab8b733db14ccdf28/interpreter/binary/encode.ml#L502
The 0x69 there is the 105 near the end of my wasm array.
latest Clojure alphas seems to give ClojureScript a decent small boost, 8-10% faster compile times.
what part in Clojure 1.13 is responsible for this? the array-map keyword change?
there's lot's of little tweaks around the performance of merges
it's not clear that all of those things can translate, for example increasing the PAM threshold for keyword-only maps seems like a performance loss for CLJS.
yeah I guess you don't have to do that if it does mean a performance loss