How is it possible that when we have a scrollable regular `Column` that fills the screen with conten...

# compose

[Ville Orkas]

How is it possible that when we have a scrollable regular Column that fills the screen with content the scrolling performance is very bad. But when we switch to an AndroidView that just contains a ScrollView and the content of the page wrapped in LinearLayout that contains a few ComposeView elements that render the same exact content as the full Compose solution, the scroll performance is much smoother. What is Compose doing in this case that is causing so much overhead?

[efemoney]

Share the code for both…someone might be able to spot why its not as performant.

(Check that youre not comparing apples to oranges by making sure this is done on a release build)

[Ville Orkas]

Yes its a release build, but the hardware we are using is old (10+ years) and only running Android 5.1.1. We've tried to optimize this for ages but our conclusion is that its just something inside Compose that is causing the overhead and we cannot do anything to it ourselves.

[efemoney]

Okay makes sense. I think sharing the code here might be helpful

[Ville Orkas]

I dont think the code matters here, you can just imagine scrolling a page with the usual stuff: images, text, buttons, horizontal scrollers etc. Nothing special.

[efemoney]

Well not sure what else to suggest other than, say, you might need to profile both implementations and see just where most of the UI thread time is spent.

[Ville Orkas]

I wish profiling would tell us something. And if it did, it would be inside Compose internals.

[Kata]

Scroll performance can be bad if your view recomposes a lot

[Ville Orkas]

We have checked, there are no unnecessary recompositions

[Ville Orkas]

Or constant recomposition

[dorche]

The only way for people to help would be if you could share 2 minimal examples, maybe even video recording of both. Also if you raise an issue on the issuetracker a lot of people would +1