I've been playing with `js-framework-benchmark` ap...

# kilua

[Robert Jaros]

I've been playing with js-framework-benchmark application and new SlotTable implementation for different targets and compose based web frameworks. Here are my current results:

[Letter]

I was wondering about this, thanks! Unfortunate to see the slowdown for JS :(

[Robert Jaros]

I don't understand this. It's the same application and the same tests. Let's look at the clear rows test. It's just removing large number of nodes from the composition. The same composition and the same number of nodes. On Wasm the new linked list SlotTable is about 10% slower (109 -> 119). On JS it's 100% (170 -> 338). It looks like some kind of bug for me.

[bashor]

1. Are the benchmark published?
2. Have you used production builds?
3. Is the benchmark sources available somewhere?

[Robert Jaros]

1. No. 2. Yes

[Robert Jaros]

3. Are you asking about sources of the application?

[bashor]

yes

[Robert Jaros]

https://github.com/rjaros/compose-html-js-framework-benchmark

[Robert Jaros]

Here you can select old SlotTable https://github.com/rjaros/compose-html-js-framework-benchmark/blob/main/src/jsMain/kotlin/com/sample/Main.kt#L83

[Robert Jaros]

I've updated the project to make it as fast as I was able to, but I'm not Compose HTML expert. I tested the changes in Kilua project first, and just followed the same path.

[bashor]

Thanks for sharing! Can’t promise to look at it immediately but it’s interesting to take a look at performance profiles.

[Robert Jaros]

Spliting the data in chunks and grouping is required with the old slottable implementation (it just can't handle 10_000 nodes).

[Robert Jaros]

The new implementation works, but the grouping is still faster.

[Robert Jaros]

So I'm still using it even though it's not very idiomatic 😉

[Robert Jaros]

If this significant performance drop on JS is related to some nasty bug, then maybe fixing it will possessively affect other targets like Wasm or Android as well.