1. Is there any roadmap for dealing with performance issues? I have just tried to run my compose app on an older phone and it lags bad. Specifically scrolling through LazyColumn and Pager is very laggy. 2. Does it make sense to use RecyclerView / old ViewPager - insert them into a composition and fill them with composables? Is it gonna make it faster or slower? 3. Is there anything I can do to maybe trace the performance issues (more things like this) or any specific modifiers or composables which should rather be avoided? [Edit] my specific issue is more or less solved, some explanation in thread.

In reverse order, 3) ui.perfetto.dev is one of the tools we use frequently to investigate performance. 2) based on our benchmarks you'll see similar performance between the LazyColumn/RecyclerView or ViewPager/Accompanist Pager in all-views, all-compose, or mix and match configurations. 1) Can you post your code so that we can determine if what you're seeing is something we're tracking/have addressed/is specific to what your code is doing?

Thanks for response @Adam Powell. I have lots and lots of stuff there, it's a book reader app, the main thing there is a Pager with book pages and then each page consists of a LazyColumn of different sections. I should probably try to reduce it to some smaller example and then get back to you, wdyt? I do have some vector icons there and some are repeated, will look into it. So you say that compose views should already be performant like the traditional ones with a few small exceptions? Because I read this today and it chilled me a bit: https://github.com/android/compose-samples/issues/21

😄 I wouldn't worry too much about an issue filed and closed in 2019. An immense amount of performance optimization has landed in compose over the past 6 months in particular

alright, so the plan is - I try to profile it a bit first, and if I can't find the culprit, I make a small repro - I understand that a gist with a Composable should be enough, not a full app, right?

yep, anything that can fit in a

markdown code snippet

on the issue tracker is even better, but gists or even sample apps can be helpful too.

thanks, will get back to you here 🙂

Another thing is make sure you measure the performance using release builds as debug builds are unoptimized and there can also be a lot of extra code (such as live literals support code) which will affect performance.

that too, yes. r8 makes a difference as well

I hope, there will be some thing like this in Compose as well to debug performance issues. https://twitter.com/luka_bernardi/status/1402045202714435585?s=20

we've got some really neat stuff on the debugging front in mind 🙂 nothing to share just yet though

Okay, I think there are 3 components to this: 1. release+r8 vs debug is night and day, didn't expect this to play such role - compose adds a lot of this debug stuff? - the difference wasn't so apparent with the old views, I think. 2. I have a quite simple vector icon (down arrow) which is repeated a lot in these layouts. If I remove it, scrolling becomes a bit smoother. 3. I use Coil to load images from disk (they are attached to those books). Sometimes there are quite a few of them shown as thumbnails (think dozens) and their original size is significant. When I replaced them with some 300x200 lorempixel it made a huge difference. I expected Coil to downsize the files automatically based on the view size (it's constrained to be 100dp high), but I begin to suspect that it doesn't reduce them since they are loaded from disk, not network. Will try to force resize them to thumbnail size or try Glide instead. These 3 things make the app run at least as smooth as the old one. When it comes to those vectors, is there any issue I could follow? Anyway, as always 5 ⭐ support @Adam Powell :D

great to hear! Are you using the coil composables from accompanist? cc @cb if there's any potential issues in there

Image(
                painter = rememberCoilPainter(
                    request = Uri.parse(photo.image.filePath),
                    fadeIn = true
                ),
                contentDescription = null,
                modifier = Modifier
                    .height(100.dp)
                    .padding(horizontal = 8.dp)
                    .clickable { onGalleryShown(GalleryState(tNote.photos, i)) },
            )

this is how my coil Image looks, it's powered by accompanist indeed

@Michal Klimczak the difference isn't as noticeable with Views because they are precompiled ("AOTed") as part of the system image

Yeah, I'm also noticing some funkyness with accompanist coil. Things that use coil accompnist to load images just aren't as snappy as they were in the view world and sometimes (rarely but it does happen) my composables just won't display an image. I have a lot of composable wrapped in AnimatedVisibility and I figure maybe its related to that. I plan on getting some heads down time next week to make a small repro as I thought it'd iron itself out by now.

If you remember, CC me on that repro pls @Colton Idle :)

The issue with that example is that you’re not constraining the height. Just providing the width isn’t enough to know what size to load. Set a height, minimum height or aspect ratio on the composable, and it should work better.

Thank you @cb. Will do. [Edit] I wrote more but then read the issue and realised where the problem lies :).

Has anything changed about it: yes Have we shared anything about the results yet: no, not yet 🙂

Waiting patiently :D

Awesome, thanks!