Google is making a lot of changes to Compose internals swapping regular collections and some existin...

# compose-web

[jw]

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]

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]

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]

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]

I unfortunately did not take good notes since this was just a for fun project https://github.com/ToxicBakery/Accidental-Noise-Generator/issues/1

[jw]

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

[jw]

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]

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

[jw]

Long still very bad. High and low 32-bit values....

this.m3_1 = new Long(-1478467534, -1720727600);

[Robert Jaros]

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

[jw]

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]

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

[jw]

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

[jw]

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

[shikasd]

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]

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

[Arkady Bazhanov]

Found some comparisons in the context of Scala.js: https://github.com/tc39/proposal-bigint/issues/117
And an interesting presentation about its approach to longs: https://lampwww.epfl.ch/~doeraene/presentations/jslongs-vmm2017/

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

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

[jw]

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.