Google is making a lot of changes to Compose internals swapp

Question

Google is making a lot of changes to Compose internals swapping regular collections and some existing specialized collections for different specialized collections ScatterMap et al which are even more specialized for reducing allocations This is great except those collections make heavy use of `Long` which has abysmal performance in JS targets Is JetBrains thinking about this going to do anything about it We rely on Compose running in JS heavily note not Compose UI nor Compose Web and so we re quite sensitive to performance

ian.shaun.thomas · Answer

I would love to see some improvements around long and double in js I have an accidental noise generator project which demonstrates just how abysmal performance of both of those are Would hate to see this in compose too

jw · Answer

Is double slow That s JS s intrinsic number type Anyway I m not proposing fixing Long since it s probably mostly impossible obviated by WASM but the widespread change to use ScatterMap puts a lot of Longs on the hot path that otherwise weren t there before Nothing in ScatterMap requires a Long it could just as easily use Int or even 48 bit integers stored in JS s native number which has 53 bits of integer precision but today the sole implementation is hardcoded to 64 bits Long

ian.shaun.thomas · Answer

IIRC yes long and double both had wrapping around them so every math call like 0 3d 0 4d resulted in a dozen calls on the stack and for something like accidental noise that basically explodes performance immediately

ian.shaun.thomas · Answer

I unfortunately did not take good notes since this was just a for fun project <https github com ToxicBakery Accidental Noise Generator issues 1|https github com ToxicBakery Accidental Noise Generator issues 1>

jw · Answer

I do not see doubles being wrapped in my JS for what it s worth

jw · Answer

Here s the implementation of a constructor that accepts a `Double` and has a default argument expression for example ``` if 0 === seen1 8 $this q3p 1 = 1 0 else $this q3p 1 = density ```

ian.shaun.thomas · Answer

Nice Maybe it was just Long I ll have to look again

jw · Answer

Long still very bad High and low 32 bit values ```this m3 1 = new Long 1478467534 1720727600 ```

Robert Jaros · Answer

Can I somehow try this new compose runtime with Kotlin JS or Kotlin Wasm in my project

jw · Answer

Not unless you build it the runtime yourself Google doesn t build those targets and it s not integrated into the JetBrains fork yet

jw · Answer

I assume you d also have to build the collection library for the JS target where ScatterMap and friends are written

jw · Answer

It s not too hard but definitely not as easy as changing a dependency string

jw · Answer

Note that WASM should have no real issues here since it has a 64 bit wide integer type

shikasd · Answer

It seems like some browsers support bigint types for numbers e g `42n` in <https developer mozilla org en US docs Web JavaScript Reference Global Objects BigInt64Array>

jw · Answer

Yeah but they re still pretty slow Although still probably better than emulated Longs

Arkady Bazhanov · Answer

Found some comparisons in the context of Scala js And an interesting presentation about its approach to longs

Zach Klippenstein (he/him) [MOD] · Answer

I shared this internally there was some discussion about it Did you file a bug in JB compose I can link to

jw · Answer

Not yet I ve also been talking to Romain about it directly I haven t done any actual performance testing yet Was kinda being lazy and waiting for JB to publish collections with a JS target but I can build my own