It seems closures is used a lot in Compose, for ex...

# compose

[molikto]

It seems closures is used a lot in Compose, for example onClicks and childrens. Because they are created each time when a composible function is called, so they are not equal to the previous closure. So does it cause unnecessary compose? Are there plans to address this (like comparing captured variables)?

[Adam Powell]

Yes it creates a lot of unnecessary work right now and yes there are plans in flight to address it 🙂

[Thierry]

This was always a major PITA with react.

[Thierry]

Solution was typically to use shouldComponentUpdate

[Thierry]

what's the plan for Compose?

[Leland Richardson [G]]

we are still figuring out what the right approach will be. But there is a combination of things we can do.

We are exploring generating code around lambda literals in composable functions that checks the capture scope against the previous version and memoizes the lambda allocation based on it (this generally amounts to generating remember calls around lambdas automatically.

This helps us, and we think we can do it in a way that doesn’t change developer expectations.

There’s also some other strategies we are considering that are complimentary, where a lambda essentially becomes an @Model, and this means that when the value changes, it can still skip the execution of the composable it is passed into if the lambda is only invoked deeper down the tree, and instead we just skip to the point of invocation. We call this “donut hole skipping”. It’s something we are experimenting with right now but early results point to this being a pretty sizable perf win.

[Leland Richardson [G]]

(the latter one is a bit harder to explain what is going on, but this transformation would also be such that user expectations shouldn’t need to change at all)