I’m trying to confirm my logic here. But if I have...

# compose

[Elyes]

I’m trying to confirm my logic here. But if I have 100 items of a Text composable that shows the index of the item. Then if the screen can render 10 at a time, when I scroll the whole page, I should find a recomposition count of 1 on each item of the new page right? Since the previous page items would have been reused.
I’m scrolling and scrolling and nothing is recomposing until very far into scrolling, which drives me to think that nothing is recomposed.

This is causing me lag when I have an AsyncImage in my item, as that composable may be expensive to compose.
Also, I’m checking the heap dump, and at the start there are as many allocation for the item composable as what’s rendered in the screen which makes sense. But then as I scroll more and more and more allocations are added. Is this normal? Doesn’t this indicate that the composables are not being reused?

I’m testing with this simple list:

@Preview
@Composable
fun TestPerformance() {
    val list = remember {
        List(100) { it }
    }
    LazyColumn(
        modifier = Modifier.fillMaxSize()
    ) {
        itemsIndexed(list, contentType = { _, _ -> 0 }) { index, item ->
            TestItem(index)
            Spacer(modifier = Modifier.height(10.dp))
        }
    }
}

@Composable
fun TestItem(index: Int) {
    Surface(
        color = Color.Green,
        modifier = Modifier.size(100.dp)
    ) {
        Text(text = "#$index")
    }
}

[ascii]

It's not limited to how many items are screen-visible. See screenshot; defined in LazyListScrollPosition.kt

[ascii]

causing me lag when I have an AsyncImage in my item

Are you testing on a release build? I have a UI with 400 items in a LazyColumn (no pagination). 3 Texts, 1 AsyncImage, 1 IconButton.

No noticeable lag or performance issues on a 3 year old flagship, but I haven't done a proper benchmark. Debug stutters around a bit.

[Elyes]

It’s not limited to how many items are screen-visible. See screenshot; defined in LazyListScrollPosition.kt

Not sure how this relates to the issue 🤔

Are you testing on a release build?

Yep I’m seeing the issue with a release build as well.

[Vlad]

@ascii using what library for the AsyncImage?

[ascii]

Coil

[Vlad]

I see. Coil is good.
I use a smaller KMP image loading library which does the very visible spikes on scrolls.

[ascii]

Which one? I'll try that out to compare

[Vlad]

It is called seiko

[Vlad]

https://github.com/qdsfdhvh/compose-imageloader

Well it is not, but its packages are seiko

[Albert Chang]

when I scroll the whole page, I should find a recomposition count of 1 on each item of the new page right?

No. Reusing a node is not the same as recomposing, and won’t be counted as recomposition.

[Vlad]

Although will be fair to say that I use 2 months old version of the library, and I see in the releases that it has few updates.

[Elyes Mansour]

@Albert Chang I see! Could you put a few words on the difference or point me to somewhere where i can read more on the subject?

Also what about the huge number of allocations. On a list of 100 items, I’m easily seeing more than 300 allocations for the item composable.

Also I’ve noticed the behavior where the scrolling becomes smoother after a few scrolls back and forth in the whole list. What would explain that?

[Albert Chang]

Could you put a few words on the difference or point me to somewhere where i can read more on the subject?

I’m not sure why you are confusing them (perhaps because of RecyclerView?) but they are … just different things. An obvious difference is that when a node is reused, all its states are cleared (as you surely wouldn’t want a new item to inherit the states of an old item), which is not the case when it’s recomposed. If you want to know more you can read the source code of SubcomposeLayout.

Also what about the huge number of allocations.

Why not just check what the allocations are?

Also I’ve noticed the behavior where the scrolling becomes smoother after a few scrolls back and forth in the whole list. What would explain that?

Likely because of JIT.

[P Valintelis]

Btw, similar issues here https://kotlinlang.slack.com/archives/CJLTWPH7S/p1695113646842899 . Especially with Coil. It is quite weird that people ignore these problems.