Hello. When doing some experiments with compose ru...

# compose

[Robert Jaros]

Hello. When doing some experiments with compose runtime I'm observing a significant performance degradation with a repeatable dependence on the number of recompositions. I've even made a chart of my data (see 🧵). Can anybody explain what could be the cause of this? Perhaps someone has encountered a similar issue?

[Robert Jaros]

compose.png

[Robert Jaros]

As you can see there is a significant degradation at the beginning, then between 7K and 9K recompositions and again between 13K and 15K.

[Robert Jaros]

I'm using compose multiplatform 1.6.0 on web targets (js, wasm).

[Robert Jaros]

Thankfully it seems to be problem in my code and not compose itself 😉

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

This doesn’t seem surprising - the more work you do, the more time it will take to do it

[Robert Jaros]

The direct reason of the issue was creation of new MutableState instances and execution of composable functions subscribed to this state on every recomposition. The state was created with the remember function, but the composables were continuously removed and added to the composition, so remember didn't help. The strange thing, I'm not sure I understand, is what should happen to the state object and all subscriptions when composable leaves the composition. I think it should be canceled and disposed, and at the first look it was happening (the composable functions were not executed). But with a great number of recompositions the performance was degrading, as if compose was still referencing those "disposed" state objects and processing them somehow.

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

adding and removing things from the composition isn’t free. If you’re doing that enough on every frame, you’re going to see a performance hit. I’m curious why you’re adding/removing so much?

[Robert Jaros]

I'm experimenting with server side rendering by running a compose web app in nodejs, orchestrated and recomposed by incoming requests. I realize compose was definitely not designed for this 😉, but in general it seems to work quite fine (especially after resolving this performance issue and with wasm target speed).

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

that seems fine in theory

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

doesn’t explain why there’s so many recompositions. Maybe the models coming from your server aren’t being compared correctly?

[Robert Jaros]

I was generating these recompositions on purpose just to stress test the engine.