are these skipped recompositions a performance issue?

# compose-android

[nglauber]

are these skipped recompositions a performance issue?

[Shahzad Ansari]

Nope, skipped recompositions means that your content didn't to be recomposed and was using the previous values it had.

[dewildte]

Why would they be a performance issue?

[dewildte]

They are the very thing that make up good performance in Compose Lol

[nglauber]

Explaining the context a little bit...
I'm implementing a server-driven UI. So, basically, my UI is observing a tree. Then, if some element of the tree has changed in the server, I receive the new tree and pass it to the composable function.

[dewildte]

Got it!

[dewildte]

SDUI is fun stuff

[dewildte]

I did some of that awhile back.

[Stylianos Gakis]

If anything, the non skipped ones would be a performance issue, not the skipped ones.

[shikasd]

As someone who did some of tree diffing, consider calculating list of changes on server and only updating subtrees that changed.
Clients are usually less performant/efficient at processing those updates and Compose still has to go through equality checks for nodes top-to-bottom.

[nglauber]

@shikasd you touched the exact point that I need to know.
In fact, the server is actually giving me the exact node that has changed... But how can I refresh a specific item in the compose view tree? 🤔

[dewildte]

How are you structuring the data you feed into compose?

[nglauber]

Imagine that I'm passing a tree (a Node object which can contain children).
Something like:

ServerUi(node=root)

inside of the ServerUi I'm checking...

when (node.tag) {
"text" -> // call a Text composable
"column" -> // call a Column
"button" -> // call a Button
// etc..
}

[dewildte]

So you have no way to find the backing node by it’s ID and ask it to update it’s state?

[nglauber]

Yes, I have.

[dewildte]

Is the state observable by the composable rendering it?

[dewildte]

If so, then that composable should be able to update itself in place, no?

[nglauber]

Yes. The root node is observable. But when I update a child node (at some level of the tree) and I pass the updated tree to the ServerUi composable, what happens is that skip counter of the other elements increase

[dewildte]

If only the root node is observable then you have to rebuild the entire UI again when it changes.
I am no expert at this, but I might approach it with something like this:

Untitled.cpp

[dewildte]

Build your tree out of these things (or something like it) and control it from a ViewModel.

[dewildte]

You could index the nodes in a Map and find the node by ID and tell it to update it’s properties.
Or you could just do a traversal of the tree until you find the one you want and tell it to update.

[shikasd]

@nglauber consider wrapping each node with a mutable state and update it in place :)

[nglauber]

Thanks @shikasd and @dewildte.
I tried but didn't work... Maybe I missed something

[nglauber]

Update: it worked. Thanks, guys 😉

[dewildte]

What did you do and why was it not working before?

[nglauber]

It was a few mistakes in my logic... 🙂
• In my data structure, the text of a Text server element was considered a leaf of my tree. Then I was trying to update the state using the ID of the leaf, where I should use the ID of the parent.
• Another issue was that I'm using a data class in the state, and a var field was not being considered in the equals function, so Compose was not considering the state change and the recomposition was not working...
There were a few more things... But to summarize, it was all my mistake 😄