I've a doubt on the diff alghoritm used by compose with `AdapterList` . The composable receives a re...

# compose

[manueldidonna]

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<Item>() }

AdapterList(items) { item -> 
    ItemUI(item, onClick = { items = /** new read-only List with only one item changed**/ }) 
}

Should I replace the MutableState with a ModelList?

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

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

[manueldidonna]

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

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

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&ss=androidx%2Fplatform%2Fframeworks%2Fsupport

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

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.

[manueldidonna]

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

[manueldidonna]

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

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

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.

[manueldidonna]

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

[manueldidonna]

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

[caelum19]

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