A modern programming language that makes developers happier.

kotlinlang

I've a doubt on the diff alghoritm used by compose with `AdapterList` . The composable receives a read-only `List`, each item has a proper equals method. If an item must change, the composable is invoked with a new list.

```var items by state { emptyList&lt;Item&gt;() }

AdapterList(items) { item -&gt; 
    ItemUI(item, onClick = { items = /** new read-only List with only one item changed**/ }) 
}```
Should I replace the `MutableState` with a `ModelList`?

What is your doubt? `AdapterList` should support regular immutable `List`s just fine.

Screenshot_20200612-162623.jpg

I had bad performance on scrolling. The UI is very simple. I thought it was a problem with the immutable list. So it's not an AdapterList fault. If needed I can share the code in the next hours. Maybe it's useful to understand how I got these horrible performance

Looking at the source code, `AdapterList` doesn’t actually do any diffing. When you pass a new `data` list in, it looks at the indices of the data items that are currently on screen and re-invokes your `itemCallback` for whatever data happens to be at those indices at that point in time. So in terms of time complexity, every update to the data is recomposed in roughly constant time relative to the number of items that can be on the screen at one time, it doesn’t matter how large your list is. So you’re right it’s probably not an `AdapterList` issue. But it would be good to attach the profiler and look at what methods are actually taking so long.

<https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:ui/ui-foundation/src/main/java/androidx/ui/foundation/AdapterList.kt;l=80?q=adapterlist&amp;ss=androidx%2Fplatform%2Fframeworks%2Fsupport>

Scrolling doesn’t mutate the list though, does it? So the type of the list shouldn’t matter. If the individual item composables are expensive, that seems like the most likely candidate for this, although again it’s simple to attach the profiler in Android Studio and see what’s actually going on.

I will update this thread asap with the profiler data. Thanks Zach!

Using the profiler I get that the problem is not related to the data passed to the composable. The majority of the calls is to the measure method of the layouts with a lot of InfPxSize, Constraints, etc.. instances allocated. This was one of my first times with the profiler tool, I'll investigate further in the next days to understand the cause of the problem

I think there was a pretty big optimization pass over the layout/measurement code that landed recently, but idk if it shipped yet. Might help with some of that stuff.

Do you remember which was the commit? I would see it

In the past 2 weeks I've seen a lot of commits on the optimizations of the layout. But It's strange that I am the only one who complained of such low performances

Did you ever find what could be causing the lag? Getting some lag with my scrolling too