Thread
#compose
    manueldidonna

    manueldidonna

    2 years ago
    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]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    What is your doubt?
    AdapterList
    should support regular immutable Lists just fine.
    manueldidonna

    manueldidonna

    2 years ago
    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]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    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.
    manueldidonna

    manueldidonna

    2 years ago
    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
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    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

    manueldidonna

    2 years ago
    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
    caelum19

    caelum19

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